16:00:08 <ildikov> #startmeeting cinder-nova-api-changes
16:00:10 <openstack> Meeting started Thu Jun 22 16:00:08 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:14 <openstack> The meeting name has been set to 'cinder_nova_api_changes'
16:00:20 <ildikov> johnthetubaguy jaypipes e0ne jgriffith hemna mriedem patrickeast smcginnis diablo_rojo xyang1 raj_singh lyarwood jungleboyj stvnoyes
16:00:33 <mriedem> o
16:00:38 <mriedem> o/ i mean
16:00:38 <stvnoyes> o/
16:00:48 <ildikov> :)
16:01:01 <ildikov> we have a couple of Cinder guys out
16:01:18 <ildikov> let's wait a minute to see whether we have more people to show up today
16:02:25 <ildikov> ok, let's start and go through things quickly
16:02:46 * jgriffith sneaks in and hides in the back
16:02:46 <ildikov> stvnoyes: did you see Matt's comments on the live_migrate patch?
16:03:04 <stvnoyes> yes, I have most of the updates done, working on the tests right now
16:03:11 <ildikov> jgriffith: I can see you there too :)
16:03:22 <jgriffith> so much for hiding :)
16:03:25 <ildikov> stvnoyes: coolio
16:03:34 <ildikov> stvnoyes: anything we should talk about here?
16:03:47 <ildikov> stvnoyes: I updated the attach PoC to address your comments
16:04:05 <ildikov> stvnoyes: playing with the tests, I'll have a few more rounds with that...
16:04:29 <stvnoyes> is anyone working on this -      https://bugs.launchpad.net/cinder/+bug/1692153
16:04:30 <openstack> Launchpad bug 1692153 in Cinder "v3 attachment connection_info formatting is different than v2" [High,New]
16:04:33 <ildikov> stvnoyes: I didn't add the target_lun fix as it's fixed in brick and should be fix long term in Cinder
16:04:50 <stvnoyes> that's fine, that's why i put it in as just an fyi
16:04:58 <ildikov> jgriffith: do you or anyone in your knowledge working on that one?
16:05:37 <jgriffith> not to my knowledge no
16:05:57 <jgriffith> we should check with hemna
16:06:02 <stvnoyes> i need to check what version of brick I'm running. any idea what version it's fixed in?
16:06:20 <ildikov> I don't think brick is released yet as they wanted a few more things in last time
16:06:26 <ildikov> I'll ask hemna
16:06:40 <ildikov> if it's not released yet you can test by installing it from source
16:06:56 <jgriffith> stvnoyes I don't believe it's fixed yet anyway... unless oslo object updated
16:06:58 <jgriffith> anyway
16:07:08 <stvnoyes> ok thx, also how about this bug - https://bugs.launchpad.net/cinder/+bug/1697526
16:07:09 <openstack> Launchpad bug 1697526 in Cinder "attachment_create fails on live migration with bfv instance" [Undecided,New]
16:07:23 <ildikov> jgriffith: hemna added a quick fix in brick to address the target_lun issue and cast it to int
16:07:50 <jgriffith> stvnoyes I can take that
16:08:04 <stvnoyes> ok that would be great thx.
16:08:31 <jgriffith> we'll need to figure out how we want to address the whole "multi-attach, but not really multi-attach" thing for lm
16:09:06 <stvnoyes> i also updated this cinder review - https://review.openstack.org/#/c/472796/  - let me know if this makes more sense
16:09:22 <stvnoyes> jgriffith - related to what you just said
16:09:53 <ildikov> stvnoyes: I added a comment to that one recently
16:10:17 <ildikov> jgriffith: you mean to allow creating multiple attachments to the same volume regardless they are multi-attach enabled or not?
16:10:57 <jgriffith> ildikov that's the weird case of live-migration
16:11:14 <jgriffith> it's actually doing two attachments, because Nova is afraid to get rid of one until the new one is made
16:11:32 <ildikov> jgriffith: I think we said something like same instance, but another host should do the trick
16:12:07 <jgriffith> ildikov yeah.. you mean inspecting that on the attachment-create and let it slide right?
16:12:08 <ildikov> live_migrate is not trivial anyway because of the switch over :/
16:12:21 <stvnoyes> btw, that review should probably be taken over by someone on the cinder team. it might go faster that way. (https://review.openstack.org/#/c/472796/)
16:12:25 <jgriffith> nothing is trivial anymore it seems :)
16:13:01 <stvnoyes> i'm happy to pass it on! :-)
16:13:09 <ildikov> stvnoyes: I planned to ping people on the channel later to figure out the strategy and fix it for lvm now
16:13:18 <stvnoyes> ok great
16:13:18 <ildikov> stvnoyes: :)
16:13:39 <ildikov> jgriffith: has anything ever been? :)
16:14:20 <jgriffith> :)
16:14:42 <ildikov> jgriffith: so attachment_create gets the volume and the instance ids
16:14:56 <stvnoyes> and then there's this bug -  https://bugs.launchpad.net/cinder/+bug/1697526 - which is a strange one
16:14:57 <openstack> Launchpad bug 1697526 in Cinder "attachment_create fails on live migration with bfv instance" [Undecided,New]
16:15:09 <stvnoyes> nope. not that one
16:15:18 <jgriffith> deja-vous
16:15:28 <stvnoyes> this one - https://bugs.launchpad.net/cinder/+bug/1697775
16:15:29 <openstack> Launchpad bug 1697775 in Cinder "cinder v3 api: show hides some attachments" [Undecided,New] - Assigned to NidhiMittalHada (nidhimittal19)
16:16:04 <stvnoyes> i guess it could be related to the cinder v3 work, but it doesn't seem like it
16:16:13 <jgriffith> ildikov so the trick is it would also need the connector, unless we just decide same instance is safe
16:16:57 <jgriffith> stvnoyes I think I know what's going on there btw
16:17:06 <ildikov> jgriffith: I'm unsure whether we only need to reserve the volume or we attach it too before detaching it from the source host
16:17:17 <jgriffith> stvnoyes did you by chance have a mix of attachments (ie created some with the old flow and some with the new)?
16:17:43 <stvnoyes> no, i don't think so. all with the new flow.
16:18:07 <jgriffith> The other thing is keep in mind it only shows active attachments in the volume-show
16:18:23 <jgriffith> the one at least was "reserved" and not "attached"
16:18:38 <jgriffith> but we can look and verify if that's what's going on or not
16:18:44 <stvnoyes> it causes problems with the attachment_delete which is looking at attach count.
16:19:07 <stvnoyes> so while you think there is only one attachment, in reality there are several
16:19:25 <jgriffith> well...
16:19:34 * jgriffith mutters to himself
16:19:35 <stvnoyes> so having 'show volume' show them all is important
16:19:58 <ildikov> can we have multiple attachments now?
16:20:10 <jgriffith> the whole point was to NOT do counting, but if we can't get the shared connection folks to "do something" I guess we're right back where we started
16:20:22 <stvnoyes> this is during migration, i noticed that at the end of the migration, the volume was not detaching
16:20:29 <ildikov> jgriffith: couldn't that work for lvm though?
16:20:45 <jgriffith> ildikov counting?
16:20:49 <ildikov> jgriffith: as it's problematic for lvm as well in my understanding
16:20:52 <ildikov> jgriffith: yes
16:20:55 <jgriffith> meh
16:21:11 <ildikov> or if not counting then what would work for that one?
16:21:16 <jgriffith> Let's move on, I'll see if I can figure out what's up with the counts
16:21:44 <jgriffith> ildikov there's a difference between going to the attachments table and trying to rely on what the volume-object says/thinks
16:21:52 <ildikov> as lvm is the reference implementation we should fix it there and then tell the drivers to implement it how it's suitable for their stuff
16:21:57 <jgriffith> and it only matters when it comes time to delete a target
16:22:17 <jgriffith> in all other cases we shouldn't be messing with the calculation of things any more
16:22:28 <jgriffith> ildikov +1
16:22:45 <ildikov> but when you detach right now it's basically deleting the target as well IIUC
16:23:14 <jgriffith> ildikov it's calling terminate, and that's where the whole topic of "drivers figure out what they need to do" came in
16:23:23 <jgriffith> anyway... I'll look at it
16:23:41 <ildikov> yeah, that's where I thought to fix it
16:24:38 <ildikov> anyway, let's move on
16:24:52 <ildikov> I added a few tests to swap_volume
16:25:20 <ildikov> mriedem: if you want to add any comments to that patch before wonderful China please do so :)
16:25:39 <mriedem> probably won't happen
16:25:41 <ildikov> jgriffith: is the Cinder side of that thing considered to be ready for review?
16:26:01 <ildikov> jgriffith: I mean annoying Cinder people to review :)
16:26:14 <ildikov> mriedem: thought so :(
16:26:20 <ildikov> mriedem: but wanted to give it a try :)
16:26:22 <jgriffith> You mean stvnoyes patch on the the terminate connection?
16:26:40 <ildikov> jgriffith: no, the migrate_volume_completion stuff
16:26:48 <jgriffith> ildikov yes
16:26:59 <ildikov> this one: https://review.openstack.org/#/c/472786/
16:27:32 <ildikov> ok, cool, I'll add it to my annoyment-list
16:27:47 <jgriffith> haha
16:28:00 <ildikov> mriedem: are off for only a week?
16:28:22 <ildikov> mriedem: also who should I annoy with the Nova side reviews besides you?
16:28:26 <mriedem> ildikov: yeah 1 week
16:28:33 <mriedem> but then it's the 4th of july US holiday after i get back
16:28:37 <mriedem> so the week after is going to be weird
16:28:52 <mriedem> ildikov: idk honestly, johnthetubaguy is still out
16:29:01 <mriedem> the other cores are busy with their own dev things
16:29:25 <ildikov> are you saying we're missing Pike?
16:29:31 <mriedem> nope
16:29:39 <ildikov> as we have roughly 4 weeks
16:30:02 <mriedem> yup
16:30:10 <mriedem> we have really 3 changes to get into nova right?
16:30:11 <ildikov> and if we need one more core who kind of needs on-boarding that'll take time
16:30:19 <mriedem> live migration, swap volume, and the attach change at the end
16:30:26 <ildikov> yep, I believe so
16:30:34 <ildikov> I'm playing with the attach patch now
16:30:46 <ildikov> swap is sort of ready for review
16:30:53 <jgriffith> swap should be pretty much ready
16:30:53 <mriedem> dan, jay, mel and sylvain are busy with scheduler and cells v2 stuff
16:31:01 <jgriffith> I'll look at LM
16:31:02 <ildikov> and live_migrate will be again soon
16:31:12 <jgriffith> kinda thought that was pretty close
16:31:18 <stvnoyes> is the Poc going to be the change for attach, or is that going to be new work? that will need a lot of work on the test side. I can start writing tests for attach...
16:31:38 <mriedem> stvnoyes: it's the poc
16:31:40 <jgriffith> stvnoyes that would be AWESOME!!!
16:31:41 <mriedem> going to be that change i think
16:31:42 <ildikov> mriedem: what about Stephen?
16:31:58 <mriedem> ildikov: i don't know how familiar he is with these flows
16:32:06 <mriedem> you can certainly ask
16:32:11 <ildikov> stvnoyes: I'm fixing tests now to make them green, but I default a lot back to the old flow
16:32:18 <ildikov> ok I'll ask him
16:32:21 <mriedem> we also need a grenade change
16:32:28 <ildikov> anyone else who might be able to chime in?
16:32:33 <stvnoyes> ok, we can talk later about it, after I get migrate back up for rv
16:32:37 <mriedem> to have a volume attached on the old side (ocata) go through an upgrade and detach it on the new side (pike)
16:32:50 <mriedem> for the grenade thing, just talk to sdague
16:32:54 <ildikov> stvnoyes: yep, let's chat about it as we can work separately on that
16:32:55 <mriedem> shouldn't be too hard to add that
16:33:49 <ildikov> yep, doesn't sound too bad except that I don't have that much clue about grenade, but it's never too late to learn :)
16:34:50 <ildikov> I think mainly that's all from my side today
16:35:05 <ildikov> while mriedem is out we can work on addressing things on the Cinder side
16:35:21 <ildikov> and I'll see who I can harass for review in Nova
16:36:15 <ildikov> anything else from anyone we should try to address here today?
16:37:23 <ildikov> ok, I take it as a no :)
16:37:43 <ildikov> mriedem: safe travels to China!
16:37:59 <ildikov> catch up with y'all separately on the different items
16:38:07 <ildikov> have a good day!
16:39:01 <ildikov> #endmeeting