21:01:24 <russellb> #startmeeting nova
21:01:25 <openstack> Meeting started Thu Apr 25 21:01:24 2013 UTC.  The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:28 <openstack> The meeting name has been set to 'nova'
21:01:28 <russellb> Howdy!
21:01:30 <russellb> who's here?
21:01:35 <sdague> o/
21:01:37 <dansmith> -o/
21:01:39 <beagles> o/
21:01:41 <morganfainberg> o/
21:01:41 <dripton> hi
21:01:44 <cyeoh> Hi
21:01:48 <russellb> people!
21:01:49 * Vek tries to decide...
21:02:00 <harlowja> me
21:02:05 <russellb> #link https://wiki.openstack.org/wiki/Meetings/Nova
21:02:20 <russellb> #topic havana blueprints
21:02:21 <morganfainberg> I'm virtually here (at best) :P
21:02:30 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2013-April/007788.html
21:02:39 <russellb> I posted that message earlier this week, please take a moment to read it if you haven't
21:02:41 <cburgess_> presnet
21:02:52 <mikal> Morning
21:02:57 <russellb> The most important thing at this point in the cycle is that we get a roadmap put in place
21:03:04 <devananda> \o
21:03:06 <russellb> you can find the roadmap in progress here:
21:03:15 <russellb> #link https://blueprints.launchpad.net/nova/havana
21:03:27 <russellb> So, if there's something you plan to work on, please file a blueprint
21:03:37 <russellb> or multiple blueprints if it's complex enough to need to be broken up into stages
21:03:56 <harlowja> alot of stuff is still up for discussion isn't it? especially the orchestration/conductor pieces...
21:04:12 <russellb> to get it on the havana roadmap, you will need to set the assignee, propose it for havana, and select a milestone that you feel is realistic for when you can have it completed
21:04:29 <russellb> harlowja: yes, lots will be under discussion, we just need to take our best shot at a roadmap
21:04:43 <harlowja> ok, roadmap seems hard when its still under discussion :-p
21:04:45 <harlowja> but ok
21:04:45 <russellb> the reason we do all this is to communicate amongst ourselves, as well as to the larger community what it is we're working on
21:04:56 <sdague> yeh, the starting point should be all the stuff which has concensus
21:04:57 <dansmith> russellb: so for the migration cleanup and the object stuff, I'm happy to go off and file those blueprints now, if that's cool
21:04:58 <russellb> lots of blueprints are filed but not on the roadmap, those are the ones in flux a bit, and that's ok
21:05:09 <russellb> dansmith: yes please do
21:05:17 <dansmith> I was waiting until today for some undefined and silly reason, I guess
21:05:17 <sdague> which I think there is a lot from summit, so best to take russellb's approach and get that all in
21:05:20 <mikal> I'm on vacation this week, I'll catch up with mine next week
21:05:26 <russellb> mikal: sounds good
21:05:37 <russellb> my goal is to have a good first cut at this done in about 1.5 weeks from now
21:05:58 <russellb> a couple other comments on the blueprint process ...
21:06:11 <cburgess_> dansmith: Is the migration one for the general cleanup and unifying all the migration code stuff and cleaning up evactuate etc?
21:06:13 <russellb> at the end of the release cycle, the blueprint list is effectively our feature list, and what we use to build release notes
21:06:30 <russellb> as you are reviewing, please be looking for feature patches without a blueprint, and ask for one to be filed
21:06:31 <dansmith> cburgess_: yeah, and unifying all of that to conductor, as we discussed
21:06:46 <harlowja> dansmith: please can we finish discussion on that before it suddenly appears
21:07:02 <russellb> another review thing ... when reviewing patches that have a blueprint, please make sure it is on the roadmap before approving
21:07:11 <dansmith> harlowja: appearing as a placeholder can happen before we hash out all the details
21:07:15 <harlowja> ok
21:07:20 <russellb> if something needs to be ACKed for the roadmap, you can ask me, or anyone on nova-drivers
21:07:41 <russellb> and it can either be approved, or they may ask for a discussion to make sure there is concensus on the ML first
21:08:02 <harlowja> sounds good
21:08:04 <russellb> ok, that's all my notes on blueprint process.  any questions on the process?  also feel free to discuss specific blueprints if you'd like.
21:08:10 <russellb> we can also discuss them in open discussion at the end.
21:08:26 <boris-42> hi all
21:08:52 <sdague> rmk and vishy were looking various nova-network => mutnauq upgrade things, any idea if either of them are going to put in something for deprecating nova-network?
21:09:16 <russellb> sdague: that's a good point, we need something for that.
21:09:21 <dansmith> long live nova-network!
21:09:36 <russellb> sdague: it's unclear what code work is needed ... it's basically "figure out the migration path"
21:10:01 <sdague> yeh, true, though I imagine some of that upgrade code will need to be in tree
21:10:06 <russellb> yep
21:10:16 <sdague> but it's worth not loosing as a thing
21:10:17 <russellb> i'll add that to  my notes for something to chase down
21:10:18 <mikal> Yeah, its likely they'll need to configure multiple API endpoints for example
21:10:21 <russellb> agreed
21:10:25 <rmk> sdague: I think that may have been cburgess actually
21:10:46 <rmk> and hi yes I am here
21:10:48 <sdague> rmk: ok, it was day 4, so I was a little fuzzy by then :)
21:10:48 <russellb> one of the problems is that no one person has taken clear ownership over this effort
21:11:06 <rmk> sdague: no worries, I was a zombie too by then
21:11:10 <russellb> a few people volunteered to do some necessary research
21:11:30 <russellb> so maybe i'll take it for now, at least to track who is researching what
21:11:34 <russellb> and keep it moving
21:11:37 <vishy> russellb: I think you could consider me+garyk as the owners
21:11:47 <russellb> vishy: ok that would be awesome
21:12:02 <russellb> vishy: i'll file a nova blueprint and set you as the assignee (since we can have only one)
21:12:17 <senhuang> vishy: do you have any update on the blue print to coordinate the schedulign of nova and cinder using current rpc mechanism?
21:12:26 <russellb> vishy: do you want to file a blueprint for it?
21:12:54 <russellb> vishy: not sure what we'd call it ... perhaps it's just deprecate-nova-network, and it's just whatever we need to complete to feel good about doing that
21:13:23 <harlowja> senhuang: i'd like to see that also, or maybe u can create one?
21:14:09 <senhuang> harlowja: i have one for unified resource placement module, which is more like a centralized approach that sits on top of nova and cinder
21:14:26 <harlowja> senhuang: so there u go, how can we make that start to appear :-p
21:14:30 <russellb> ok, let's cover a few other topics, then we can come back to specific blueprints at the end
21:14:41 <russellb> #topic feature patch proposal deadline
21:14:49 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2013-April/007823.html
21:14:55 <russellb> I put out this proposal on the list earlier this week
21:15:10 <russellb> basically if we're going to reject patches for coming in too late, i want to communicate that clearly ahead of time
21:15:21 <harlowja> that seems to be ok with me
21:15:23 <russellb> i picked a date out of the air, which was 2 weeks ahead of the official feature freeze
21:15:23 <sdague> I think it's a good call
21:15:25 <dansmith> +1000
21:15:28 <sdague> +1
21:15:30 <senhuang> +1
21:15:32 <morganfainberg> +1
21:15:40 <cburgess_> +1 FIrm dates are great we can all work toward that and plan.
21:15:43 <cyeoh> +1
21:15:46 <boris-42> +1
21:15:47 <russellb> ok cool.
21:15:54 <russellb> it would be good to record your support on the ML thread
21:15:59 <harlowja> sure
21:16:00 <dansmith> russellb: gee, I think that has enough support
21:16:13 <dripton> I didn't know Dan got a thousand votes.
21:16:18 <harlowja> just might want to be some wording when this happens to not piss people off, haha
21:16:29 <russellb> if anyone has an objection let me know ... otherwise I'll work on making sure it's communicated effectively
21:16:56 <russellb> harlowja: well that's why i'm trying to establish it as early as possible, so it's not a surprise ... unless it's your fault for not paying attention
21:17:05 <dansmith> dripton: as you know, a bunch of +1's don't add up to a +2 :)
21:17:12 <harlowja> russellb: agreed
21:17:24 <sdague> dripton: it's binary, so it's only 8 votes
21:17:26 <russellb> dansmith: aw, harsh man, they do to me, depending on who the +1s are from :)
21:17:41 <morganfainberg> sdague: lol
21:17:46 <dansmith> sdague: nice
21:18:07 <dansmith> russellb: heh, well, I was trying to downplay my obvious over-vote for that, given that everyone else only allocated +1 for it :)
21:18:16 <russellb> alright, next topic, maybe we can finally disagree on something
21:18:20 <russellb> #topic baremetal split
21:18:28 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2013-April/007979.html
21:18:35 <russellb> #link https://wiki.openstack.org/wiki/BaremetalSplitRationale
21:19:01 <harlowja> drum roll
21:19:04 <harlowja> nm, ha
21:19:05 <russellb> please review that, ponder it, and make your opinion known if you have one
21:19:08 <rmk> I don't even know what this is yet but yes
21:19:16 <russellb> yeah, it was just posted today
21:19:20 <russellb> so people need time to review it
21:19:25 <russellb> but i wanted to make sure awareness was raised.
21:19:27 <russellb> devananda: ^
21:19:30 <rmk> honestly bare metal doesn't fit well at all in nova
21:19:31 <devananda> yep, thanks
21:19:39 <devananda> i believe it's still waiting moderation on the -tc list, too
21:19:41 <russellb> OpenStack Bare Metal (Ironic)
21:19:42 <mikal> russellb: does a split count as a new incubation request for the TC?
21:19:45 <russellb> i'm a fan of the codename.
21:19:54 <russellb> mikal: yes, it will be a TC issue to consider
21:19:55 <dansmith> I've already said this, but I'm +1 on the Ironic proposal
21:20:05 <morganfainberg> i'd say in the current way baremetal works, it would be good to move it out of nova into it's own project.
21:20:11 <russellb> mikal: but I'd like to drive more broad consensus before the TC votes on it or anything
21:20:11 <devananda> mikal: as far as i've been told, this would bypass incubation and follow the same path Cinder took
21:20:16 <harlowja> me to, it will be interesting to see how it plays out, hopefully good in the end
21:20:17 <morganfainberg> russellb: agreed on the code name.
21:20:23 <rmk> The name I'm impartial to but +as_many_as_possible to splitting it out
21:20:43 <rmk> The use case is just so vastly different than dealing with VMs
21:20:45 <devananda> mikal: since the code's already in a core project
21:21:14 <russellb> but what we *don't* want is for this to be seen as a fast track method to being an incubated project
21:21:22 <rmk> aside from being cleaner, it gives the project a much better chance of success since it'll be able to adapt to vastly different bare metal needs
21:21:27 <russellb> as in, instead of starting off on your own, try to grow in an existing project and split off, because it's easier/quicker
21:21:28 <devananda> russellb: indeed
21:21:40 <senhuang> devananda: will this bare metal project also support one VM is spawned on the bare metal and possesses all the resources exclusively?
21:21:43 <russellb> rmk: yeah, agreed, i'm pretty sold on the idea
21:21:54 <rmk> russellb: It seems to me this was more a result of discovering that it didn't fit well than anything intentional
21:22:16 <russellb> rmk: oh sure, not accusing that here, i'm just worried about precedent, and abuse of the pattern elsewhere
21:22:16 <devananda> senhuang: i'm not sure i follow your question, but i think the answer is yes, it already does
21:22:20 <dansmith> rmk: I'm skeptical of that devananda guy and his intentions
21:22:25 <mikal> Heh
21:22:25 <rmk> dansmith: totally
21:22:27 <devananda> :)
21:22:29 <rmk> he's pretty sketchy
21:22:35 <dansmith> long hair and everything
21:22:39 <sdague> heh
21:22:44 <mikal> I think it can't hurt to run it quickly through the TC, and perhaps truncate the incubation process
21:22:52 <morganfainberg> russellb: as long as it's clear the reason for the split, i think it shouldn't become a pattern.
21:22:53 <mikal> dansmith: he also bites his dogs!
21:22:57 <sdague> yeh, well during the review cycle it was clear it fit oddly
21:23:01 <dansmith> mikal: *gasp*
21:23:02 <rmk> it's probably easier to figure out if anyone objects to this
21:23:11 <russellb> i think i saw him with a trench coat on, too
21:23:11 <rmk> because it seems like we couldn't possibly be in more agreement
21:23:13 <russellb> which can't be good
21:23:22 <devananda> senhuang: take a look at https://github.com/tripleo/incubator/blob/master/README.md and see if that answers some of your questions. it's a special case for baremetal
21:23:31 <senhuang> devananda: okay. cool. thanks!
21:23:34 <russellb> yep, so everyone here seems happy with it ... please continue comments on list
21:23:40 <devananda> mikal: only when necessary!
21:23:45 <russellb> even +1s on the list are quite helpful to showing consensus
21:24:18 <russellb> anything else on bare metal?
21:24:23 <harlowja> devananda: are the ntt people working with u, might be useful to have there advice, since they are likely using the code that exists and might know more about the migration path?
21:24:35 <devananda> harlowja: very little
21:24:39 <russellb> we would have to go through a deprecation path for this
21:24:50 <harlowja> devananda: hmmm, interesting
21:24:52 <russellb> just like any other drastic change like this ... a deprecation cycle, migration path
21:25:05 <devananda> since they handed the project to us iat the grizzly sumit, they've been pretty quiet
21:25:17 <devananda> arata sends in patches and bug fixes often
21:25:31 <sdague> devananda: it would be nice to try to draw them in on the new effort
21:25:34 <devananda> and the ISI folks added tilera/pdu support right after FF ended
21:25:48 <russellb> yep, that landed for havana
21:25:48 <devananda> sdague: indeed. mikyung was in the session when we talked about this
21:25:54 <devananda> and didn't voice any objection
21:26:03 <devananda> which is about as much assent as i have gotten from them :)
21:26:09 <harlowja> ya, wonder if they can provide more input, since my guess is ntt, isi are using it more than at least y! is
21:26:37 <harlowja> so there feedback would seem pretty valueable if u can draw said feedback out of them
21:26:50 <devananda> i'll try to ping them directly // off list and see
21:27:04 <russellb> ok cool, one more quick topic, then we can go to open discussion
21:27:06 <russellb> #topic bugs
21:27:21 <senhuang> we also have usage for it in some dev/ops. one comment I got from them is that it would be nice to have a common api to provision bare metal and vm..
21:27:21 <russellb> let's not let all this fun future work let us forget about bugs :)
21:27:25 <russellb> #link http://webnumbr.com/untouched-nova-bugs
21:27:36 <russellb> 34 untriaged bugs right now
21:27:58 <russellb> not *terrible*, but we should be watching, as we probably have bug reports coming in as people try out grizzly
21:28:16 <senhuang> russllb: could you response to my comment on but https://bugs.launchpad.net/nova/+bug/1049249
21:28:19 <uvirtbot> Launchpad bug 1049249 in nova "Remove plugging of internal classes from configuration" [High,Confirmed]
21:28:29 <russellb> *everyone* can help with triage, if you're not sure how, see this page:
21:28:30 <russellb> #link http://webnumbr.com/untouched-nova-bugs
21:29:00 <russellb> senhuang: i guess it's valid as long as that option exists
21:29:15 <russellb> senhuang: the compromise/solution has been moving things to entrypoints with short names
21:29:26 <senhuang> russellb: okay. i probably need more guide on this bug..
21:29:32 <russellb> so it'll still be pluggable, technically, but not so obviously directly exposed in the config file
21:30:11 <russellb> any other bug comments or questions?
21:30:33 <russellb> if we all triage just a couple this week, we'll be in much better shape (that goes for most weeks, really ..)
21:30:34 <boris-42> yes
21:30:47 <boris-42> should I report bug for each race condition?
21:30:52 <boris-42> before adding UC?
21:31:01 <harlowja> more races, eck :(
21:31:08 <boris-42> less races=)
21:31:09 <morganfainberg> russellb: the URL link form webnumbr shows only one bug?  am I misunderstanding the function of that link?
21:31:19 <russellb> morganfainberg: it showed 34 for me?
21:31:28 <harlowja> boris-42: the glass is half-full, good attitude
21:31:28 <sdague> boris-42: you've got a blueprint for all the UC stuff though right?
21:31:32 <sdague> I'd just use that
21:31:42 <russellb> agreed, the bp is fine ...
21:31:53 <russellb> technically you can associate bugs to a blueprint
21:32:00 <russellb> but ... no need to create extra work unnecessarily
21:32:09 <sdague> yeh, but I think the bp is fine, the uc work is a well known quantity
21:32:09 <russellb> if you *want* to create bugs, it's fine with me, but you don't have to
21:32:14 * russellb nods
21:32:18 <morganfainberg> russellb: something off in my web-browser then.  *shrug*
21:32:21 <dripton> morganfainberg: it shows 38 for me, but only displays one of them due to windowing.  Says "1 of 38"
21:32:37 <morganfainberg> dripton: i think it's an extension going dumb on my browser.
21:32:43 <harlowja> boris-42: has there been any thought on the races that are at a level above the DB?
21:32:53 <harlowja> read/write/modify types
21:33:01 <russellb> you can also look at https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
21:33:08 <russellb> not quite the same, but close enough
21:33:44 <boris-42> russellb what do you prefer adding bugs or not for races?) I just don't now is there any reason for spamming bug tracker?)
21:33:53 <russellb> just use the bp
21:34:00 <boris-42> russellb ok
21:34:27 <russellb> #topic open discussion
21:34:30 <devananda> harlowja: afaik, no one's really looking at those races above db/api -- except for quotas
21:34:40 <harlowja> devananda: durn
21:34:43 <devananda> harlowja: if you have some in mind, please open bug reports and tag with 'db'
21:34:50 <boris-42> harlowja I think that there is also a lot of races=)
21:34:53 <harlowja> kk, i have a few, do orphaned resources count
21:34:57 <harlowja> boris-42: 100% agreed
21:34:58 <sdague> yeh, even better is tests
21:35:05 <russellb> yay tests.
21:35:12 <boris-42> <3 tests
21:35:16 <sdague> then we can keep them from showing up again
21:35:50 <boris-42> Btw I have some question about pci devices...
21:36:07 <boris-42> There is already about 4 BP for that!
21:36:21 <boris-42> One task but 4 BP =)
21:36:47 <russellb> yes that area is a bit of a mess
21:37:01 <russellb> a good example of what happens when people don't talk enough
21:37:09 <boris-42> probably we should chose one of that
21:37:18 <russellb> yeah.
21:37:18 <boris-42> There is also problems with USB
21:37:38 <boris-42> if we are using host dev pci passthrough in libvirt
21:37:51 <harlowja> sdague agreed on tests, but if u just look at pieces of the nova code, u can spot these things, but maybe its just my mindset
21:37:55 <boris-42> then we are able to passthrough only USB controllers
21:37:56 <senhuang> I have a question on the nova's api extension
21:38:13 <harlowja> oh thats a good one, senhuang what happened to the nova extension refactoring effort thingy
21:38:21 <sdague> harlowja: then bring tests to the table that demonstrate it
21:38:29 <boris-42> We should make a little bit different operation for USBs
21:38:30 <harlowja> sdague: sounds good :)
21:38:51 <harlowja> challenge accepted :-p
21:38:59 <senhuang> harlowja: i am still researching on how to do api extension for nova
21:39:01 <russellb> boris-42: i think you're on the right track by going back and documenting your design
21:39:14 <russellb> boris-42: then hopefully everyone interested can discuss if it meets their requirements
21:39:24 <russellb> boris-42: and the people most involved with the libvirt driver can provide feedback as well
21:39:28 <russellb> boris-42: then we can move forward
21:39:28 <harlowja> senhuang: just in general how to do them, or how to make the api extension mechanism easier?
21:39:40 <cyeoh> re: API extension framework I'd appreciate any feedback on https://review.openstack.org/#/c/27276/ - would like to get that moving soon as we can't really do much v3 API work until at least some basic support is in.
21:39:52 <harlowja> for the later i thought there was https://etherpad.openstack.org/NovaAPIExtensionFramework
21:39:54 <senhuang> harlowja: on general how to do it
21:39:57 <harlowja> ya, with chris
21:40:08 <morganfainberg> cyeoh: i'll look it over today/tomorrow and give you feedback
21:40:10 <harlowja> senhuang: i can try to help, its not so clear
21:40:15 <boris-42> russellb Yes I am working on it, so there should be some changes in my approach to provide PCI passthrough and USB passthrough in one common approach=)
21:40:16 <senhuang> harlowja: that is pretty cool! thanks
21:40:25 <cyeoh> morganfainberg: thanks!
21:40:26 <harlowja> senhuang: ya cyeoh just pointed that out
21:40:26 <russellb> boris-42: ok
21:41:29 <senhuang> cyeoh: that is awesome. i will look at it
21:42:39 <russellb> any other topics for the day?
21:42:53 <russellb> please ping me anytime over the next week if you need assistance getting blueprints in shape
21:42:59 <senhuang> any one have time to take at look at this blue print?
21:43:19 <senhuang> https://blueprints.launchpad.net/nova/+spec/unified-rpm
21:43:20 <boris-42> btw is there some info about no downtime migrations?
21:43:42 <russellb> boris-42: i wasn't in that session, so not sure what was discussed
21:43:59 <devananda> a lot was discussed about versioned db objects
21:44:01 <harlowja> russellb: i'd like to hear how conductor can become something like orchestration, or understand at least from a design perspective how, just so i can accomodate it in my wiki and blueprints and such
21:44:11 <devananda> IMO, that led to being able to do no-downtime-db-upgrades
21:44:17 <russellb> senhuang: yeah, i saw that one ... it seems like there's not clear consensus on how to approach that problem yet.
21:44:25 <devananda> or no downtime service upgrades for all services, including db and conductor
21:44:40 <devananda> so, are there any BP up for versioned db objects?
21:45:05 <senhuang> russellb: maybe we could first provide a well-defined api extension and achieve consensus on the api?
21:45:09 <russellb> harlowja: I started talking about this on a thread on the ML today.  I feel like we've got some work combining code paths for migrate/live-migrate/resize/evacuate, and part of that will be moving it to conductor.  that's the first step here.
21:45:22 <harlowja> how does moving it to conductor work?
21:45:24 <russellb> senhuang: has there been a ML thread on this?
21:45:32 <dansmith> devananda: well, we're focused on internal objects first,
21:45:35 <senhuang> russellb: not yet
21:45:41 <dansmith> devananda: then versioning those and isolating schema changes along with that
21:45:55 <harlowja> russellb: i hear lots of moving to conductor but never have seen how it would get there or even if it makes sense there, shouldn't that be part of the discussion?
21:45:56 <dansmith> devananda: I think we don't expect to really hit the big versioning parts until post-H, realistically
21:45:57 <russellb> senhuang: ok, that's where we need to discuss it basically.  I think having a proposal for what the API would look like would aid that discussion.
21:45:59 <senhuang> russellb: i am in discussions with garyk on the api
21:46:02 <devananda> dansmith: yes. i mean, is that plan written up anywhere?
21:46:10 <russellb> senhuang: but it's not clear that there is even agreement that it should be a new separate thing, so we need to work through that.
21:46:13 <dansmith> devananda: the internal objects one?
21:46:36 <dansmith> devananda: I just filed a blueprint, and we talked about it on IRC a bit, but I need to fill out the blueprint with more details  yet
21:46:37 <devananda> dansmith: i could see maybe 3 BPs covering internal versioned objects, then rpc forwards/backwards compat, then db stuff
21:46:42 <russellb> harlowja: it has been discussed a whole bunch, and we had a session dedicated to cleaning up these code paths where we discussed it further.
21:46:45 <devananda> dansmith: ack
21:47:00 <harlowja> russellb: where's the docs on how that will be done?
21:47:02 <dansmith> devananda: yeah, I've got three now, actually, almost exactly like that.. still need to make the deps between then and fill out the details
21:47:03 <sdague> senhuang: things like that really need to get to general concensus on the mailing list first
21:47:18 <devananda> dansmith: great :)
21:47:23 <devananda> boris-42: ^
21:47:26 <senhuang> russellb: that is true. i think i still need to provide more details
21:47:32 <russellb> senhuang: ok, sounds good
21:47:43 <senhuang> sdague: yep. that is probably a good idea
21:47:54 <harlowja> russellb: can u possible re-explain to me how said stuff fits in the conductor
21:48:16 <devananda> russellb: on the conductor-does-evacuate stuff, i'd like Heat considered in that situation too
21:48:27 <harlowja> devananda: me too, or at least a common library for this stuff
21:48:30 <harlowja> which nova uses
21:48:39 <devananda> russellb: as in, if there's an auto scaling group, how that'll be impacted by conductor doing things automagically
21:48:39 <sdague> devananda: you realize "evacuate" isn't what it sounds like, right? :)
21:48:40 <harlowja> we shouldn't keep on reimplementing custom workflows
21:48:45 <russellb> devananda: sure.  note that we're *not* talking about doing anything automatically
21:48:54 <devananda> russellb: ahh. didn't realize that :)
21:49:00 <russellb> nothing automagic, all triggered from the outside like it si now
21:49:05 <dansmith> devananda: I don't want conductor doing automagic stuff, btw
21:49:09 <devananda> sdague: i /think/ i know what it does
21:49:19 <russellb> this is just about turning a bunch of separate code paths doing much of the same thing into common code where it makes sense
21:49:20 <dansmith> devananda: I want heat doing all the orchestration of failover type stuff from the outside entirely
21:49:29 <russellb> and also, in the cases of migration and such, we have compute nodes telling each other what to do
21:49:30 <devananda> dansmith: ++
21:49:36 <russellb> we don't want any compute nodes telling any other compute nodes what to do at all
21:49:41 <sdague> devananda: the current "evacuate" action restarts vms that were on a machine that it toast
21:49:44 <russellb> so the solution is to move most of the processing up a layer
21:49:57 <devananda> sdague: cool. that's what i thought
21:50:14 <harlowja> russellb: so thats great, but thats not explaining how conductor will do it, thats just explaining the general principle right, how does conductor change to be said thing, especially when i am planning something that can do said tasks also, likely something that will use this heat library
21:50:23 <russellb> harlowja: dude, chill
21:50:33 <russellb> :)
21:50:41 <harlowja> trying, just i don't get it :-p
21:50:51 <russellb> harlowja: i think more formal state tracking is good, but we need a place for it to plug in cleanly, and we don't have that yet
21:50:53 <senhuang> i agree on the general principles :-)
21:50:55 <russellb> so this code cleanup is step 1
21:51:18 <harlowja> confused, isn't making the foundation correct step #1?
21:51:21 <russellb> have to look at the steps it will take to get to where you want to go, and i really believe these are the first steps
21:51:26 <harlowja> then moving said code cleanup onto said foundation
21:51:57 <russellb> we have to do it in logical steps, not an enormous patch set that rewrites everything
21:52:08 <russellb> i understand what you want, and i think we can get there
21:52:09 <harlowja> isn't that possible with a good foundation?
21:52:09 <sdague> harlowja: it seemed pretty clear in the room that it was a pretty good incremental cleanup
21:52:09 <russellb> ... in stages
21:52:27 <harlowja> i still think it can be done in stages, with a good common library first though, not secondary :-p
21:52:28 <sdague> I really think it's unrelated to orchestration
21:52:48 <harlowja> sdague: how so?
21:52:53 <sdague> harlowja: hey, nothing prevents you from proposing alternative incremental code
21:53:05 <harlowja> sdague: and thats where its a waste of time to do
21:53:07 <russellb> true :)
21:53:17 <russellb> so here's the thing ...
21:53:18 <russellb> we have code
21:53:20 <russellb> a whole bunch of it
21:53:38 <russellb> we want to do some cleanup, combining, and slight restructuring of that code as an incremental step
21:53:40 <sdague> but I think rehashing consolodating the migration paths isn't very useful, because it's a huge win
21:54:03 <sdague> from a verification stand point especially, as right now the whole live migrate path isn't testing at all in gate
21:54:10 <sdague> which is the suck
21:55:28 <sdague> but at the end of the day, code talks. bring something more clean, and more useful to the table, and it will be evaluated.
21:55:46 <dansmith> everyone interested in doing the work for the unified migrations path seems to be in agreement,
21:55:51 <dansmith> so I don't think we really have a problem here
21:55:56 <harlowja> sdague: i have code for the foundation of this, haha
21:56:15 <russellb> would be good to see it on the list
21:56:18 <russellb> i don't think i have seen it yet
21:56:28 <dansmith> harlowja: propose it and we'll handle it in gerrit
21:56:32 <harlowja> it was shown in the summit :)
21:56:39 <sdague> dude, I have piles of code :) that doesn't mean it's more useful for openstack in all situations.
21:56:41 <russellb> yeah, but lots of people weren't at the summit
21:56:51 <russellb> i also had a session conflict (rpc stuff, and i'm one of the few maintainers of that code)
21:57:15 <harlowja> ok, will send that out again
21:57:19 <russellb> k
21:57:25 <dansmith> I have to run
21:57:27 <russellb> anything else?  just a few minutes left in our time.
21:57:30 <russellb> k, later dansmith
21:57:43 <harlowja> just i'd like to really understand clearly how the future of conductor fits into the plans, even incrementally
21:57:58 <russellb> i honestly am not sure how to better explain it
21:58:21 <harlowja> write it down?
21:58:25 <harlowja> draw pictures?
21:58:37 <russellb> we can continue out-of-meeting
21:58:39 <russellb> thanks everyone!
21:58:41 <russellb> #endmeeting