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