16:00:01 <ildikov> #startmeeting cinder-nova-api-changes
16:00:02 <openstack> Meeting started Thu May  4 16:00:01 2017 UTC and is due to finish in 60 minutes.  The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'cinder_nova_api_changes'
16:00:07 <mriedem> o/
16:00:10 <jungleboyj> o/
16:00:11 <ildikov> DuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr ebalduf patrickeast smcginnis diablo_rojo gsilvis  xyang1 raj_singh lyarwood breitz jungleboyj
16:00:26 <stvnoyes> o/
16:00:30 <hemna> \0
16:00:36 <hemna> @!
16:00:36 <pewp> hemna (╯°□°)╯︵ ┻━┻
16:00:46 <ildikov> hemna: already? :)
16:00:54 <hemna> yah, why not :P
16:00:56 <jungleboyj> @!h
16:00:56 <pewp> jungleboyj (/ .□.) ︵╰(゜Д゜)╯︵ /(.□. )
16:01:22 <jungleboyj> It is a good way to start any meeting.
16:01:25 <ildikov> pre-Summit meeting, I get it... :)
16:01:31 <ildikov> ok, let's start then
16:02:18 <ildikov> I see mriedem added a few comments to shutdown_instance
16:02:46 <stvnoyes> saw those, starting on that
16:02:53 <ildikov> I think local_cleanup is also ready for review: https://review.openstack.org/#/c/456851/
16:03:02 <ildikov> stvnoyes: am I right? ^
16:03:05 <stvnoyes> yes
16:04:08 <ildikov> mriedem: so please add comments to that one too ^^ :)
16:04:21 <mriedem> already doing it
16:04:56 <ildikov> we started to discuss migrate_volume_completion with the Cinder team and in my understanding to conclusion is to look into how to use the new calls with it
16:05:32 <ildikov> so we plan to keep the same call back method concept and have it covered in the new API
16:06:03 <ildikov> at least my expectation is that it's more clear that way, but maybe we can update the existing call easily
16:06:37 <ildikov> e0ne will help looking into the current version and figure out the new API (compatible) solution
16:07:00 <ildikov> so in this sense swap_volume in Nova is on hold currently until the Cinder side is done/fixed
16:07:32 <ildikov> in the meantime stvnoyes is looking into live migrate to see what the challenges are there
16:08:00 <mriedem> so what do you mean by the 'new' api in cinder?
16:08:12 <ildikov> mriedem: the new attach/detach API
16:08:16 <mriedem> because if migrate_volume_completion doesn't handle this for 3.27, then cinder needs a new microversion for that
16:08:50 <smcginnis> mriedem: We still need to determine if we need a new API call or not.
16:09:01 <mriedem> ok
16:09:12 <mriedem> like, nova might not need to call migrate_volume_completion at all?
16:09:22 <mriedem> or you plan on doing something in 3.27 maybe to handle it if it's a new-style attachment?
16:09:28 <mriedem> like as a bug fix?
16:09:32 <smcginnis> Bug fix.
16:10:31 <ildikov> is there an option that does not need new microversion?
16:10:42 <ildikov> just for my understanding :)
16:11:03 <smcginnis> ildikov: If we can make the current call handle the new attachment correctly, then we don't need a microversion bump.
16:11:16 <smcginnis> But if we need to add a new API, or somehow change the current one, then that will need it.
16:11:20 <hemna> smcginnis, +1
16:11:33 <smcginnis> But that's the part I am not clear on - which of those we need to do.
16:12:47 <smcginnis> Down side being with NOT doing a microversion bump, there will be no way externally to know if the version of cinder present can handle this or not.
16:13:25 <ildikov> smcginnis: I just wanted to ask whether that's a bug fix to backport
16:13:45 <smcginnis> ildikov: If we can fix the current method, then definitely we will get that backported.
16:14:15 * johnthetubaguy wonders in late and hides at the back
16:14:33 <ildikov> smcginnis: ok, cool, I think that was my concern
16:14:39 <ildikov> johnthetubaguy: hi :)
16:15:03 <ildikov> johnthetubaguy: we discussed swap_volume and migrate_volume_completion briefly
16:15:19 <johnthetubaguy> yeah, just scrolling back
16:15:43 <ildikov> johnthetubaguy: let us know if you have further questions or comments
16:15:55 <johnthetubaguy> smcginnis: do a microversion bump to just signal the new stuff is there?
16:16:17 <smcginnis> johnthetubaguy: We could. But then we can't really backport that.
16:16:21 <johnthetubaguy> downside is we probably would then no want to trigger the new flow until that microversion is there
16:16:28 <smcginnis> +1
16:16:34 <johnthetubaguy> yeah, I guess we just said the same thing in two different ways
16:16:39 <smcginnis> :)
16:16:56 <johnthetubaguy> why would we need/want to backport it?
16:17:07 <smcginnis> If we can do it as a bug fix and get it backported, I don't think we would have too big of a window until it's out there.
16:17:28 <ildikov> if we do a version bump, then we need to check that higher version when we add attach
16:17:37 <johnthetubaguy> ildikov: yep
16:17:42 <smcginnis> Just to allow Ocata Cinder with Pike Nova. But then again, maybe we don't care and just make it the new required level.
16:17:45 <ildikov> or we do what smcginnis says
16:18:03 <johnthetubaguy> the silent backport sounds way too much like cheating in a way we will break things
16:18:17 <johnthetubaguy> smcginnis: so Nova just uses the old flow if cinder is too old, so its OK I think
16:18:32 <johnthetubaguy> I mean, its not idea... but life sucks sometimes
16:18:48 <smcginnis> johnthetubaguy: Yeah. Was just hoping we had all the pieces in place to not have to do that.
16:18:51 <smcginnis> But maybe not.
16:18:51 <johnthetubaguy> so cleanest option is a new API we pass the old and new attachment ids too?
16:19:12 <smcginnis> First we need to figure out this code and understand what we actually need to do.
16:19:22 <smcginnis> I have not touched that, and most who have recently are gone.
16:19:24 <mriedem> yeah before we rathole,
16:19:36 <smcginnis> So we just need to refresh our knowledge a bit.
16:19:37 <mriedem> let's figure out what actually needs to happen on the cinder side for migrate_volume_completion
16:19:39 * johnthetubaguy things mriedem saw we typing
16:19:43 <johnthetubaguy> thinks^
16:19:47 <smcginnis> mriedem: +1
16:19:48 <johnthetubaguy> me^
16:19:53 <mriedem> if it's a request body change or something, it's definitely microversion bump
16:19:56 <ildikov> e0ne is not around, but offered to help by having some knowledge about the current code
16:19:59 <mriedem> so until we sort that out, let's move on
16:20:03 <smcginnis> +1
16:20:12 <johnthetubaguy> so migrate_volume_completion let get clear on what it does
16:20:32 <ildikov> yep, that's the plan
16:20:34 <mriedem> also note that we should be able to attach/detach with 3.27,
16:20:45 <mriedem> but maybe not swap volume until a later microversion or something; nova as client code can determine that
16:20:50 <johnthetubaguy> I think... it makes volume B look like volume A, we currently pass in A and B, but that only happens if the user called cinder to migrate volume A
16:21:18 <johnthetubaguy> if the user called nova to swap A and B, non that really happens, I am not sure if the cinder call actually does anything in that case
16:22:06 <johnthetubaguy> mriedem: I kinda like the one high water mark, if I am honest, makes life less complicated (please upgrade to make swap volume work with your newly attached volumes, etc)
16:22:23 <smcginnis> Certainly safer.
16:22:29 <mriedem> sure, just stating options
16:22:37 <mriedem> but let's move on - todo is on cinder to figure out what needs to happen
16:22:38 <ildikov> mriedem: so that means if a volume is attached in the new way then you cannot swap that if you don't have the high enough microversion, if we go down that path
16:24:00 <ildikov> #action Cinder team to figure out how to handle migrate_volume_completion on the Cinder side
16:24:15 <jungleboyj> smcginnis: ildikov  We are planning to get together with e0ne to talk about this next week.  Right?
16:24:22 <ildikov> I'm ready to move on
16:24:35 <smcginnis> Let's move on.
16:24:45 <ildikov> so as jungleboyj brought it up
16:24:50 <smcginnis> jungleboyj: Yes
16:24:54 <jungleboyj> :-)
16:24:54 <ildikov> do we want a small sub-team gathering next week?
16:25:25 <johnthetubaguy> at this point I have free lunch times and break times
16:25:26 <ildikov> like mriedem johnthetubaguy would you be interested to join?
16:25:41 <mriedem> my schedule is full
16:25:53 <smcginnis> johnthetubaguy: There's always between 11pm and 6am. :)
16:26:01 <johnthetubaguy> there is the Nova and Cinder forum session, we could get onto this if we "have spare time"
16:26:07 <mriedem> smcginnis: you and i are in customer meetings at those times
16:26:16 <smcginnis> mriedem: Sadly true
16:26:18 <mriedem> there isn't a nova/cinder forum session,
16:26:29 <mriedem> the one you're thinking of is specifically about using cinder for ephemeral
16:26:36 <mriedem> and volume affinity
16:26:38 <johnthetubaguy> yeah, thats the one
16:26:45 <mriedem> those aren't this though
16:26:46 <johnthetubaguy> oh, so thats like 2 hours of material already
16:26:55 <johnthetubaguy> yeah, no spare time there
16:27:01 <ildikov> yeah, we could reserve a slot in a hacking room
16:27:04 <jungleboyj> :-(
16:27:08 <mriedem> there are spill over rooms on thursday afternoon,
16:27:37 <smcginnis> Maybe let's just try to get a hacking room time reserved, then whoever can make it can make it.
16:27:42 <mriedem> ok
16:27:45 <ildikov> which I hope we can do with a few Cinder guys
16:28:01 <mriedem> i'm totally happy if the cinder team can get together and figure out all of the problems
16:28:15 <ildikov> smcginnis: yep, I will sync up with e0ne and try to figure out when (if) jgriffith is available
16:28:25 <ildikov> mriedem: :)
16:28:33 <smcginnis> +1
16:28:46 <jungleboyj> :-)
16:29:01 <ildikov> ok, we can take finding a slot offline
16:29:21 <ildikov> stvnoyes: is there anything for live migrate to talk about here today?
16:31:01 <ildikov> I take it as a no :)
16:31:30 <ildikov> I don't have additional topics for today, I don't think it would worth going into other things before get swap and migrate figured out
16:31:40 <ildikov> obviously no meeting next week
16:31:47 <mriedem> i'm +2 on the local delete patch,
16:31:57 <mriedem> and the shutdown_instance one should be simple to address my -1
16:32:01 <mriedem> just decouple that refactor
16:32:04 <ildikov> mriedem: I saw, thank you
16:32:18 <ildikov> johnthetubaguy: if you have a minute plz check the local_cleanup patch
16:32:31 <johnthetubaguy> I will try look at that
16:32:45 <ildikov> johnthetubaguy: it's a pretty small one at least
16:32:51 <ildikov> johnthetubaguy: thank you
16:32:52 <mriedem> i can update the review priorities etherpad too
16:33:01 <ildikov> mriedem: sounds good, thanks
16:33:39 <ildikov> is it ok to have the next meeting the week after the summit?
16:33:48 <smcginnis> ildikov: Works for me.
16:34:12 <mriedem> sure
16:34:16 <jungleboyj> ildikov:  Yep.
16:34:44 <ildikov> cool, then I'll send out a mail to the ML that next week is cancelled and hopefully we will have some meet for swap to discuss two weeks from today
16:35:08 <ildikov> anything else from anyone for today?
16:35:18 <mriedem> oh btw
16:35:24 <mriedem> https://review.openstack.org/#/c/459113/ was updated
16:35:31 <mriedem> that's the attachment_update method
16:35:38 <mriedem> so should be good for review again
16:36:00 <ildikov> mriedem: awesome, thank you!
16:36:17 <ildikov> mriedem: I'll check after the meeting
16:36:27 <johnthetubaguy> yeah, me too
16:37:29 <ildikov> if nothing else, then thanks everyone for today
16:37:34 <ildikov> safe travels!
16:37:43 <smcginnis> See you all in Boston.
16:37:45 <ildikov> and see you next week! :)
16:37:53 <jungleboyj> See you next week.  Safe travels!
16:37:55 <ildikov> literally :)
16:37:55 <johnthetubaguy> +1
16:38:43 <ildikov> #endmeeting