17:00:29 <alaski> #startmeeting nova_cells
17:00:29 <bauzas> like DBZ ?
17:00:30 <openstack> Meeting started Wed Dec  3 17:00:29 2014 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:34 <openstack> The meeting name has been set to 'nova_cells'
17:00:39 <bauzas> 30 years of Dragon Ball !
17:00:43 <alaski> Hi everyone
17:00:44 <melwitt> Hello cellz
17:00:49 <mriedem> nothing like DBZ
17:00:52 <belmoreira> hi
17:00:52 <dheeraj-gupta-4> hi
17:00:54 <bauzas> \o
17:01:11 <vineetmenon_> hi
17:01:14 <alaski> #topic cells manifesto
17:01:21 <alaski> https://etherpad.openstack.org/p/kilo-nova-cells-manifesto
17:01:30 <bauzas> LGTM
17:01:43 <alaski> cool
17:01:45 <mriedem> oo nice
17:01:48 * mriedem needs to read it
17:01:52 <alaski> it wasn't clear if anyone had looked at it yet
17:01:57 <edleafe> o/
17:02:05 <bauzas> yeah, EU people have an advantage because we were not eating Turkey :)
17:02:14 <alaski> I think I have a few changes I'd like to put in for discussion, but due to a short week haven't gotten to it
17:02:16 <bauzas> alaski: I'm +1 on it
17:02:19 <mriedem> that's a disadvantage right?
17:02:32 <alaski> seems like it to me
17:02:50 <mriedem> alaski: so once we're good with the etherpad, where does that go?
17:02:55 <mriedem> devref? blog? other? beuler?
17:03:09 <bauzas> devref IMHO
17:03:15 <bauzas> + blog
17:03:15 <dansmith> I think it needs to hit the mailing list, but not in etherpad form
17:03:18 <alaski> mriedem: devref ultimately, also an operator list post, and a blog would be good as well
17:03:40 <mriedem> ok, yeah, ML would be good (and not in etherpad so random joe can mark it up)
17:03:48 <dansmith> do we want to just propose that as a devref thing, perhaps with alaski's diagrams,
17:03:50 <dansmith> and send that to the ML?
17:03:56 <mriedem> i'd be good with that
17:04:11 <alaski> yeah, sounds good
17:04:11 <bauzas> +1
17:04:14 <mriedem> if i'm going to read it, i might as well do it in gerrit
17:04:24 <belmoreira> dansmith: +1
17:04:32 <alaski> dansmith: you want to take that?
17:04:34 <vineetmenon_> mriedem : +1
17:04:43 <dansmith> alaski: heh, was just about to make you do it
17:04:48 <alaski> heh
17:04:50 <dansmith> but sure, we'll do it somehow
17:05:06 <alaski> yeah, I don't mind proposing it
17:05:12 <dansmith> show your diagrams
17:05:17 <alaski> #action propose manifesto to devref
17:05:27 <alaski> http://paste.openstack.org/show/144068/
17:05:35 <alaski> I forgot to add this to the agenda
17:05:40 <alaski> but I drew a few pictures
17:05:56 <alaski> I would love feedback
17:05:58 <dansmith> good ascii diagrams are like geek porn
17:06:00 <vineetmenon_> alaski: nice
17:06:13 <alaski> and want to include them in appropriate specs, and the manifesto if that helps
17:06:26 <dansmith> I think they should go with the manifesto as well, yeah
17:06:32 <bauzas> alaski: volunteering for creating yet another etherpad for diags ?
17:06:40 <alaski> bauzas: I tried that...
17:06:52 <bauzas> alaski: oh, fonts are getting you mad ?
17:06:52 <alaski> the pads aren't monospaced
17:07:13 <bauzas> alaski: eh
17:07:15 <alaski> it's a client side setting to change it
17:07:29 <alaski> so I'm happy to put them in a pad, with instructions on how to actually view them
17:07:39 <bauzas> alaski: agreed
17:08:01 <mriedem> well,
17:08:04 <mriedem> devref can link to images right?
17:08:18 <mriedem> once we're happy with the diags we could just put into an image file and store with the docs
17:08:20 <dansmith> devref can include these eaasily
17:08:23 <alaski> bauzas: https://etherpad.openstack.org/p/nova-cells-flow-diagram I need to add the last one
17:08:26 <dansmith> because they're ascii
17:08:30 <bauzas> mriedem: IIRC, there are even diagrams in devref
17:08:39 <mriedem> bauzas: yeah for the rpc stuff
17:08:58 <bauzas> mriedem: they would need some updated btw. :d
17:08:58 <vineetmenon_> alaski: etherpad just broke your diagram
17:09:07 <bauzas> *updates
17:09:12 <mriedem> bauzas: yeah, devref doesn't mention objects i'm pretty sure...
17:09:23 <bauzas> mriedem: think about betting...
17:09:52 <mriedem> what's next?
17:09:52 <dansmith> alaski: shall we move on?
17:09:56 <bauzas> alaski: that sounds acceptable for reviewing, I mean the client change in the etherpad
17:10:12 <alaski> yep, distracted by etherpad
17:10:15 <alaski> #topic testing
17:10:20 <alaski> https://etherpad.openstack.org/p/nova-cells-testing
17:10:30 <alaski> I've added a bunch of info there
17:10:31 <dansmith> ooh nice
17:10:48 <alaski> there are some reviews linked with fixes as well
17:11:05 <alaski> helping to categorize/fix the remaining failures would be a huge help
17:11:23 <vineetmenon_> since we are on testing, has anyone looked into this? https://blueprints.launchpad.net/nova/+spec/cells-tempest
17:11:28 <vineetmenon_> quite an old BP
17:11:45 <dansmith> what about it?
17:11:55 <alaski> heh, that's basically what we're doing
17:12:17 <alaski> but realistically that should be an infra bp if anything
17:12:24 <dansmith> qa
17:12:29 <vineetmenon_> dansmith, alaski: yes exactly... aren't we repeating it.. I mean that BP was basically abandoned
17:12:29 <mriedem> yeah qa
17:12:30 <alaski> or that...
17:12:31 <dansmith> or tempest or whatever, but yeah
17:12:34 <sdague> alaski: can we organize that into a list of reviews that are: merged, ready for review, wip?
17:12:38 <mriedem> but they've been fine with the patches so far it seems
17:12:49 <dansmith> vineetmenon_: it was never started
17:12:52 <dheeraj-gupta-4> alaski: very nice info
17:13:05 <alaski> sdague: yes, I can do that
17:13:06 <mriedem> sdague: yeah i was going through that list now
17:13:20 <sdague> alaski: thanks
17:13:29 <alaski> #action alaskiorganize testing etherpad into reviews that are: merged, ready for review, wip
17:14:11 <alaski> vineetmenon_: I think that bp is fine being abandoned.  if we need a new one we'll create it
17:14:21 <mriedem> https://review.openstack.org/#/c/135285/ is going through the gate
17:14:23 <mriedem> which will take awhile
17:14:30 <sdague> will definitely help on getting them reviewed in a more timely manner if we have a concise list. It would also be really nice to call out which repo the reviews are against so people will know if it's something they have +2 on before following the link
17:14:36 <vineetmenon_> alaski: sure.. I just thought mentioning it here..
17:15:13 <alaski> vineetmenon_: appreciated.  if it was a qa bp I would feel different, but most of the work isn't in nova
17:15:20 <dansmith> aye
17:15:48 <alaski> sdague: cool, we can do that too
17:15:56 <alaski> anything else on testing?
17:16:06 <mriedem> how much are we waiting on https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/flavor-from-sysmeta-to-blob,n,z now?
17:16:34 <alaski> a little
17:16:51 <alaski> I'm eager for it, but there are plent of other things to tackle still
17:17:00 <mriedem> ok, just figuring out nova review priorities since the one nova patch in there is approved, just needs gate babysitting
17:17:12 <mriedem> i've sucked at nova reviews since the break
17:17:38 <dansmith> flavors have been keeping me from reviews too
17:17:39 <mriedem> once a couple of these get in, we can go back and check test results again
17:17:40 <alaski> it will become more urgent as the list of failing tests dwindles
17:17:43 <dansmith> I need to just put it down for a day
17:17:52 <mriedem> moving on?
17:17:59 <alaski> #topic analysis of tables
17:18:03 <alaski> https://etherpad.openstack.org/p/nova-cells-table-analysis
17:18:11 <dansmith> okay, big disclaimer:
17:18:11 <alaski> dansmith put some lists together
17:18:29 <dansmith> this is just a first, uninformed pass at sorting things into global/cell scope
17:18:46 <bauzas> just one comment, could we maybe put all the etherpads in a wikipage ?
17:18:46 <mriedem> maybe you want to put that into the etherpad :)
17:18:47 <dansmith> there are a bunch I don't know what to do with, mostly because I need to look at how they're used, but some are opinion calls
17:18:53 <mriedem> bauzas: was thinking the same
17:18:58 <mriedem> global cell == global wiki page
17:19:04 <bauzas> mriedem: agreed
17:19:07 <alaski> bauzas: yeah
17:19:13 <bauzas> time for opening a wikipage, eh ?
17:19:13 <alaski> I should also be linking all of these...
17:19:18 <alaski> #link https://etherpad.openstack.org/p/nova-cells-table-analysis
17:19:33 <bauzas> alaski: yeah, I'm pretty worried of loosing focus on all etherpads
17:19:38 <bauzas> I can't track them like in Gerrit
17:19:58 <bauzas> and I'm pretty bad in making shortlinks
17:20:05 <vineetmenon_> bauzas: +1
17:20:08 <alaski> ok, I'll corral everything into a wiki
17:20:13 <bauzas> alaski: awesome
17:20:28 <alaski> as far as the tables go
17:20:32 <mriedem> alaski: feel free to delegate a bit :) if you want i can do the wiki tedium
17:20:51 <bauzas> :)
17:21:11 <bauzas> \o too
17:21:15 <alaski> it would be good to get some feedback on the preliminary organization, and thoughts on what to do with the uncategorized one
17:21:36 <bauzas> yeah, the unsure section needs debating a bit IMHO
17:21:41 <dheeraj-gupta-4> alaski do we put our comments in the etherpad itself?
17:21:48 <alaski> #action mriedem bauzas set up a wiki page to corral etherpad links for cells work
17:22:00 <bauzas> woah, 2 people on that heavy task :)
17:22:11 <dansmith> dheeraj-gupta-4: comments about the table split you mean?
17:22:23 <dheeraj-gupta-4> yes for the table split
17:22:37 <dansmith> I think this is going to be a worksheet, so lets see how it goes with people putting comments in here
17:22:48 <dansmith> just please try to keep the list readable by people as well
17:22:50 <bauzas> yeah, I'm just concerned about grouping some tables
17:22:59 <bauzas> like aggregates and instancegroups
17:23:05 <alaski> comments in the etherpad seems like a good place to start
17:23:05 <bauzas> both of them are related to scheduler
17:23:14 <bauzas> alaski: agree
17:23:23 <melwitt> comments on any etherpad content in general maybe, make comments at the bottom or something?
17:23:36 <dheeraj-gupta-4> yes comments section is a good idea
17:23:39 <dansmith> melwitt: sure, or at the bottom of a section
17:23:40 <alaski> this is very preliminary so we'll likely have to adjust how we approach this, but this is a good starting place
17:23:59 <vineetmenon_> bauzas alaski: for heated tables, I'm afraid etherpad would may become illegible..
17:24:01 <bauzas> yeah, we can do both inline and at the end of the doc, sure
17:24:15 <dansmith> vineetmenon_: that's why people need to be on their best behavior and keep the doc readable
17:24:24 <dansmith> if you want to argue about something, etherpad isn't the place anyway
17:24:30 <alaski> maybe just call out controversial tables
17:24:39 <alaski> and we can discuss here or in another medium
17:24:49 <dansmith> after we make a few passes at this, we could do another devref and argue the minutia in gerrit
17:25:14 <dansmith> the biggest problem I see here is actually the nova-network tables
17:25:14 <vineetmenon_> dansmith: +1
17:25:15 <bauzas> alaski: well, even the 2nd table about a global CellsV2 DB is debatable IMHO (compute_nodes)
17:25:30 <dheeraj-gupta-4> bauzas: +1
17:25:37 <dansmith> because I don't want to spend a bunch of time making nova-network split-able just to deprecate it
17:25:40 <mriedem> bauzas: https://wiki.openstack.org/wiki/Nova-Cells-v2
17:25:40 <dansmith> bauzas: what does that mean?
17:26:08 <bauzas> dansmith: I mean that I'm not sure that compute_nodes should be global if we consider a scheduler per cell
17:26:25 <alaski> scheduling is a whole other can of worms right now
17:26:38 <bauzas> alaski: yeah, hence my worries
17:26:40 <dansmith> bauzas: ah, well, I don't know that I think scheduling should be per-cell anyway, which is why I put it there :)
17:26:44 <alaski> but I think we should consider it orthogonal for now
17:26:46 <belmoreira> dansmith: nova-newtwork may be a requirement... depends in neutron migration progress
17:26:54 <bauzas> alaski: agreed
17:26:57 <dansmith> belmoreira: I know, that's my point
17:27:06 <dansmith> how about this
17:27:15 <bauzas> alaski: but in that case aggregates should be orthogonal, and here comes the discussion
17:27:22 <dansmith> if there are things in one or the other section, lets move them to a "contentious" section and explain why
17:27:31 <dansmith> unsure will continue to be "needs more investigation"
17:27:42 <alaski> dansmith: +1
17:27:50 <bauzas> anyway, let's put our thoughts on the etherpad, for sure
17:28:28 <alaski> it will be nice to get a list of low hanging fruit tables, like flavors and keypairs
17:28:39 <alaski> from there we can move into the contentious ones
17:28:48 <dansmith> yep
17:28:57 <bauzas> alaski: I think the sections are trying to do this
17:29:09 <bauzas> alaski: maybe some of the items need adjustment
17:29:14 <vineetmenon_> dansmith is already done with low handing fruit tables, right
17:29:32 <dansmith> vineetmenon_: this is just a proposal, it needs review and sign-off
17:29:40 <alaski> bauzas: sure, lets capture that on the pad for now
17:29:42 <vineetmenon_> dansmith: ack
17:29:44 <dansmith> like, compute_nodes was one I assumed was low hanging, but it's not
17:29:55 <dansmith> so let's see next week if people have more issues with these
17:30:00 <dansmith> after thinking/reading
17:30:12 <bauzas> +1
17:30:17 <alaski> agreed
17:30:18 <dansmith> and it would be great if folks could look at the unsure ones and try to evaluate where they belong, or at least add comments about the implications
17:30:20 <belmoreira> +1
17:30:55 <alaski> moving on
17:30:56 <mriedem> i need to read back through alaski's 2 specs first i think
17:31:07 <alaski> #topic scheduling requirements
17:31:12 * dansmith runs
17:31:22 <alaski> #link https://etherpad.openstack.org/p/nova-cells-scheduling-requirements
17:31:40 <alaski> dansmith: you're off the hook for this one
17:31:46 <dansmith> woot
17:31:59 <alaski> johnthetubaguy couldn't make it today, but he put some thoughts down
17:32:31 <alaski> he added some possible solutions at the bottom, but what I'm more interested in currently is what are the needs
17:32:57 <dansmith> so, belmoreira should add some things? :)
17:33:12 <alaski> I know what Rackspace needs, but I don't know about CERN/Nectar and non cells users
17:33:22 <alaski> dansmith: right :)
17:33:30 <dansmith> so let's specifically call out the holes
17:33:56 <belmoreira> dansmith: I need to read it...
17:34:09 <bauzas> mmm, that still relates to the discussion about a global scheduler or not
17:34:38 <alaski> bauzas: it will inform that discussion
17:34:39 <bauzas> I agree with johnthetubaguy about the scaling concerns
17:34:57 <bauzas> alaski: agreed
17:35:00 <dansmith> bauzas: it does, but we need to know what the current at-scale folks need/want/think is important
17:35:03 <alaski> belmoreira: sure, we'll touch back on this next week or after
17:35:10 <dansmith> what about some people at scale not using cells?
17:35:14 <bauzas> dansmith: yeah, I totally understand
17:35:15 <dansmith> like phil or paul?
17:35:39 <alaski> yeah, that would be great info
17:35:43 <bauzas> dansmith: I discussed with john about some scaling issues they had with the existing nova scheduiler
17:35:46 <belmoreira> alaski: for next weeks can you publish the links before the meeting?
17:36:01 <alaski> belmoreira: yes
17:36:16 <alaski> I'll add links to the agenda
17:36:22 <bauzas> dansmith: that's basically IO problems with context switching the greenthreads
17:36:29 <alaski> #action add links to the agenda before a meeting
17:36:34 <bauzas> dansmith: when they were accessing the DB IMHO
17:36:39 <dansmith> bauzas: yeah
17:36:42 <mriedem> wiki is here now: https://wiki.openstack.org/wiki/Nova-Cells-v2
17:36:42 <bauzas> s/IMHO/IIRC
17:36:44 <mriedem> alaski: ^
17:36:55 <mriedem> so we could just throw that in the meeting agenda
17:36:58 <alaski> mriedem: ahh, good point.  I can add them there too
17:37:07 <bauzas> dansmith: so I'm a little concerned about a "global scheduler" wishlist
17:37:07 <alaski> #link https://wiki.openstack.org/wiki/Nova-Cells-v2
17:37:45 <alaski> bauzas: what's your concern?
17:37:53 <dansmith> bauzas: I put "as it relates to cells" in the page, but I think we need to hear this
17:38:00 <bauzas> alaski: I just want to make sure that the scheduler can scale :)
17:38:03 <alaski> this shouldn't be a wishlist, but a list of what the current usage is
17:38:35 <bauzas> alaski: hence the CachingScheduler that john provided
17:38:37 <alaski> bauzas: so do I :)
17:38:37 <dansmith> bauzas: we don't have to do everything that is posted here, and certainly not things that aren't achievable or compatible with the overall goal :)
17:38:55 <bauzas> alaski: but I don't want to speak on behalf of him :)
17:39:13 <bauzas> dansmith: \o/
17:39:32 <bauzas> sounds like the voice of reason
17:39:37 <dansmith> next?
17:39:53 <alaski> yep, had to find my agenda tab...
17:39:57 <alaski> #topic Connection info in database or config file?
17:39:57 <bauzas> opens ?
17:39:58 * dansmith cracks the whip
17:40:00 <bauzas> oh
17:40:06 <alaski> #link https://review.openstack.org/#/c/135424/
17:40:11 <bauzas> thanks for having raised it
17:40:17 <dansmith> so, I definitely think that the connection info needs to be in the DB
17:40:25 <alaski> and I agree with that
17:40:32 <bauzas> eh eh
17:40:38 <bauzas> next then ? :)
17:40:47 <belmoreira> :)
17:40:55 <bauzas> nah, just saying it was a configuration problem
17:40:56 <alaski> I'd like to understand why a config would be useful
17:40:59 <vineetmenon_> then are you planning every config to reside in DB? or something in DB and something in file?
17:41:21 <bauzas> alaski: I'm just thinking of something that is operator-related
17:41:36 <alaski> vineetmenon_: all of it in the db
17:41:43 <alaski> vineetmenon_: regarding what's in the spec
17:41:59 <vineetmenon_> so it will need complete overhaul of existing things as well, right
17:42:06 <dansmith> vineetmenon_: not all of nova.conf of course, just this tiny piece
17:42:10 <bauzas> alaski: atm, connection URIs are stored in a conffile
17:42:11 <alaski> bauzas: I think a config makes operation more difficult as it can't be done online
17:42:27 <bauzas> alaski: well, it requires a service restart I agree
17:42:32 <vineetmenon_> dansmith, alaski: ack
17:42:45 <bauzas> alaski: do we consider autoscaling for cells ?
17:43:03 <alaski> bauzas: and for cells v1, we do store the cell relationships in the db and the mq connection info
17:43:04 <bauzas> alaski: I still need to remember my little knowledge about Heat resources
17:43:22 <bauzas> alaski: but you agree that's only for cells, not for Nova ?
17:43:25 <bauzas> in general I mean
17:43:52 <alaski> bauzas: I'm not sure autoscaling and cells go well together
17:43:57 <dansmith> bauzas: what do you mean "only for cells" ?
17:44:02 <alaski> because there's a physical component involved
17:44:06 <belmoreira> alaski: there is also the file option
17:44:07 <bauzas> alaski: so is the service restart really a problem ?
17:44:16 <dansmith> bauzas: yes
17:44:21 <vineetmenon_> bauzas: well, nova is part of cell, in one way or another.. So, I guess both
17:44:24 <bauzas> belmoreira: that's what I'm mentioning as conf file
17:44:44 <bauzas> but OK, I don't want to bikeshed things
17:44:57 <bauzas> seems like there is a large majority
17:45:06 <alaski> bauzas: yes, this is only for cells
17:45:20 <bauzas> and that's something manageable thru a nova-manage thing
17:45:28 <dansmith> alaski: but every nova deployment will have at least one of these in the table
17:45:39 <alaski> dansmith: right
17:45:43 <belmoreira> using configuration management tools is much more easy to manage configuration files
17:45:47 <dansmith> which is why I don't want to say things like "only for cells"
17:45:48 <bauzas> so, I'll change my vote and ask for something manageable, that's it
17:45:49 <dheeraj-gupta-4> If we move the connection and DB to a file, we probably won't need a cells table :)
17:45:56 <alaski> dansmith: fair enough
17:46:28 <alaski> dheeraj-gupta-4: sure, but then I have to restart my apis to add a new cell
17:46:56 <dheeraj-gupta-4> or to delete one
17:46:57 <bauzas> alaski: actually policy files are not requiring a service update
17:47:10 <bauzas> alaski: so, that's maybe an implementation detail ?
17:47:25 <bauzas> s/service update/service restart
17:47:36 * bauzas dammit
17:47:51 <mriedem> i think being able to refresh config options on the fly is a wishlist for everyone for a long time
17:47:52 <dansmith> we could do it in a config file without requiring restarts, of course
17:47:53 <alaski> belmoreira: if you're currently using config I don't want to break that for you.  perhaps we can look into a way to make them both work
17:48:15 <dansmith> I don't really see the point, TBH
17:48:18 <alaski> belmoreira: but operationally I think a db is easier
17:48:19 <mriedem> we could read the config file only for the cells group and reload the options in memory
17:48:25 <mriedem> yeah
17:48:38 <dansmith> mriedem: everything is doable, nothing about a config file requires static-ness
17:48:47 <bauzas> yeah...
17:48:48 <dansmith> the thing is, however,
17:48:52 <dansmith> if you want an API to add a cell
17:49:00 <bauzas> so the question is, what's better for cells operators ?
17:49:01 <dansmith> doing it in the config file means you really can't have that
17:49:08 <alaski> what I'm thinking is that we could load from a config into a db on startup
17:49:20 <bauzas> dansmith: that's really my question, do we envisage something orchestrating cells ?
17:49:21 <alaski> but have the db be what's actually used
17:49:30 * bauzas not saying the word "Heat"
17:49:37 <belmoreira> alaski: I think that we should go only for one solution
17:49:40 <dansmith> alaski: slightly more potentially confusing I think
17:49:40 <alaski> bauzas: I don't
17:49:42 <dansmith> yeah
17:49:50 <alaski> okay
17:50:08 <dansmith> we can change this later without too much trouble if it turns out to be a huge problem
17:50:17 <alaski> belmoreira: can you comment on the spec again with your thoughts
17:50:37 <belmoreira> alaski: sure
17:51:03 <alaski> thanks
17:51:29 <mriedem> anything left?
17:51:31 <alaski> let's bring the discussion back to the review, but maybe we're a bit closer now to consensus
17:51:46 <alaski> #topic open discussion
17:51:50 <bauzas> alaski: yeah, as said, I'll amend my comment
17:51:56 <alaski> bauzas: thanks
17:52:14 <alaski> anything for open discussion?
17:52:31 <mriedem> i'm hangry
17:52:36 <vineetmenon_> alaski: do you have anything to do for minions (me) ? specifically in testing?
17:52:37 <mriedem> let's close
17:52:50 <vineetmenon_> or specs, either
17:52:51 <mriedem> vineetmenon: scour through the testing etherpad
17:53:09 <mriedem> vineetmenon: alaski calls out the need for investigation into other failing tests
17:53:09 <alaski> vineetmenon_: mainly we could use help understanding the current failures
17:53:30 <alaski> there's a review linked with the full logs
17:53:45 <vineetmenon_> alaski, mriedem: okay
17:53:54 <alaski> or I can put up some info on getting cells running in devstack
17:53:57 <alaski> to run locally
17:54:19 <bauzas> yeah, some instructions would be awesome
17:54:26 <mriedem> alaski: don't you have a wip for that or something in devstack?
17:54:33 <vineetmenon_> alaski: that I am able to, with local cell
17:54:41 <bauzas> everytime I'm changing something in the cell namespace, I'm crossing fingers... :/
17:54:46 <alaski> vineetmenon_: cool
17:54:53 <alaski> mriedem: it's just some localrc settings
17:54:58 <vineetmenon_> region and child, right
17:54:59 <alaski> devstack does the rest already
17:55:12 <bauzas> alaski: nova-net ?
17:55:26 <bauzas> alaski: I beg your pardon, my knowledge is poor
17:55:30 <belmoreira> bauzas: yes
17:55:36 <bauzas> belmoreira: ack
17:55:53 <alaski> alright, closing up early
17:55:59 <alaski> #endmeeting