16:00:01 #startmeeting Cinder 16:00:02 Meeting started Wed May 3 16:00:01 2017 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:06 ping dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex karthikp_ patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino karlamrhein diablo_rojo jay.xu jgregor baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell watanabe.isao,tommylikehu mdovgal ildikov wxy viks 16:00:07 The meeting name has been set to 'cinder' 16:00:11 hi 16:00:12 ketonne abishop sivn breitz 16:00:14 Hi 16:00:14 hi 16:00:15 hi 16:00:20 hi 16:00:21 Hey everyone 16:00:25 o/ 16:00:27 hi 16:00:30 Hi 16:00:32 o/ 16:01:12 #topic Announcements 16:01:23 Summit/Forum is next week. 16:01:28 I hope to see a lot of folks there. 16:01:36 Hi 16:01:40 If you are giving a Cinder talk, please prepare. :) 16:02:11 * jungleboyj has only been doing that lately. ;-) 16:02:23 Also time to note - we are about a month out then from milestone 2. 16:02:28 #link https://etherpad.openstack.org/p/cinder-spec-review-tracking Review focus 16:02:31 .o/ 16:02:53 A few priority things listed in the etherpad are still in progress. 16:03:18 Biggest thing coming up to pike-2 is the new drivers, but I think the ones that are making an effort are already in a good shape. 16:03:29 2-3 or those I think may be abandoned efforts. 16:03:50 That's all I have for announcements. 16:03:53 #topic Volume migrate with the new attach/detach API 16:04:05 ildikov: Are you available for this? 16:04:14 smcginnis: tnx :) 16:04:25 jgriffith: If you are around, could be useful having your background. 16:04:40 so in the light of the new attach/detach API, I wanted to talk abou tthis call back in Cinder: https://github.com/openstack/cinder/blob/master/cinder/volume/api.py#L1457 16:05:10 which goes down to this call in the manager.py: https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py#L1905 16:05:12 Hello:) 16:05:57 as we have completely new call in full depth we need to cover the volume_migrate_completion in the new API 16:06:11 which gives us room to rethink anything we want with this call 16:06:40 so I brought this up here today to see what the team thinks about this one 16:07:26 the basic plan is to look into the current attach/detach calls and figure out how it works with Nova, like we have now detach and terminate_connection covered by one single call, which is attachment_delete 16:07:35 I think some of the most recent folks to touch the migrate code have left. Anyone with experience in that area? 16:08:31 upgrade this call to make attachment_id as one of its argument will help? 16:08:34 smcginnis: I understand how old code works but need some more time to get throw a new one:( 16:09:08 ildikov: looks like a good plan to start with 16:09:20 e0ne: Great! 16:09:27 e0ne: at this point any help is very much appreciated! 16:09:29 tommylikehu: IMO, it will this code even more complicated that it is 16:10:03 e0ne: so if you know the old code then I'll ping you later to see how to make it work with the new API 16:10:05 ildikov: Yeah, it seems like it should be updated to use the new API. 16:10:07 ildikov: not sure that I'll be very helpful this week, but we can discuss all the issues at the summit or the week after it 16:10:22 e0ne: are you attending the Summit? 16:10:29 ildikov: sure. ping me in irc if I'm online 16:10:34 ildikov: yes 16:11:00 e0ne: awesome, discussing it face to face would be even better if you're not fully booked 16:11:03 at least, I've got approved talk, and booked flight and hotel 16:11:13 e0ne: That is good. 16:11:29 We can try to pull together a little group at the summit if that helps. 16:11:36 e0ne: sounds good! :) 16:11:40 ildikov: it's pretty important thing for the cinder, so I find a time for it for sure 16:11:45 smcginnis: my thinking exactly 16:12:05 smcginnis: will bring it up on the Cinder-Nova meeting tomorrow to see who buys in 16:12:17 ildikov: ++ 16:12:27 ildikov: Where do we want to fit this in the priorities? 16:12:29 ildikov: Good plan. 16:12:39 ildikov: what is a time of nova's meeting? 16:12:57 jungleboyj: priorities of the Cinder-Nova work you mean? 16:13:03 ildikov: Yes. 16:13:18 e0ne: it's tomorrow 1600 UTC 16:13:27 e0ne: #openstack-meeting-cp 16:13:28 ildikov: noted, thanks 16:13:59 jungleboyj: it would be rather urgent in the sense of we want to cover the detach cases before moving forward with attach and in that sense I don't want to leave this hanging 16:14:24 ildikov: Ok, that makes sense. 16:14:47 jungleboyj: we will see though how much work it is in Cinder, I hope it will not be that complicated 16:14:48 ildikov: Right. As it is now, I think we cover the majority of workflows with the new API. But if someone tries migrate, it looks like that may cause issues as it is now. 16:15:09 jungleboyj: I'm not that good with hoping though nowadays, plz try not to prove me wrong :) 16:15:24 smcginnis, you can book a hacking room for this 16:15:26 ildikov: No losing hope now! 16:15:45 smcginnis: with John we gave a little bit of thought to it and it seems that migrate is the only outstanding one 16:15:47 :) 16:16:12 ildikov: Good. I couldn't think of any other cases, but I always miss something. ;) 16:16:17 diablo_rojo: it is on my TODO list already if we can come up with a rough idea when we could get together :) 16:16:28 smcginnis: I share that feeling! 16:16:53 ildikov, cool :) here is the link if you need it 16:16:53 https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms 16:17:13 diablo_rojo: awesome, thank you! 16:17:36 np 16:17:42 smcginnis: I think we covered what we could for this topic today 16:17:59 ildikov: Thanks for bringing it up. 16:18:02 if no one has any further questions/comments 16:18:14 ildikov: Thanks 16:18:30 We can follow up in the channel and at the summit then. 16:18:34 #topic Detach with no connector - is it valid 16:18:46 smcginnis: +1, thanks 16:18:54 This was an issue a lot of us hit with a new tempest test added. 16:18:55 tempest.api.volume.admin.test_volumes_actions.VolumesActionsTest.test_force_detach_volume 16:19:02 #link https://bugs.launchpad.net/cinder/+bug/1686278 Bug report 16:19:03 Launchpad bug 1686278 in Cinder "tempest.api.volume.admin.test_volumes_actions.VolumesActionsTest.test_force_detach_volume failed" [Undecided,New] 16:19:20 The crux of the issue being it calls detach without providing a connector. 16:19:26 in general, we don't need force detach at all 16:19:36 And most drivers don't know what to do if a connector isn't provided. 16:19:45 but sometimes (compute host is down) we have to use it 16:20:02 e0ne: That's probably the main use case I would guess? 16:20:12 smcginnis: I hope so 16:20:20 smcginnis: is it an issue with a new APIs? 16:20:25 if there's more than one attachment, which one is detached? 16:20:29 geguileo has been working on some force detach related stuff here: https://review.openstack.org/#/c/459454/ 16:20:30 all of them? 16:20:33 bswartz: Exactly 16:20:44 please ask him about that when he gets back next week before deciding we don't need force detach... 16:20:49 #link https://review.openstack.org/#/c/459454/ 16:21:12 eharney: we can't just drop force detach for sure 16:21:29 My question for now is actually, is it valid to call it with a connector of None? 16:21:39 eharney: we need it now and, I guess, it will be useful for some ironic use-cases too 16:21:40 And if so, what is our expectations for backend drivers to do in that case. 16:21:56 unless we define that to mean remove all attachments I don't see how it could be valid 16:22:14 and removing all attachments might not match the intended semantics 16:22:16 bswartz: That was my thought. Swanson didn't like it though. :) 16:22:41 because if you have an active user and a dead user and you only want to kill the dead user's attachment... 16:22:50 you need a way to do that 16:22:54 I would think we would at a minimum need to make sure the api-ref is very clear that if that is not provided, it means whack it all. 16:23:08 smcginnis: +1 16:24:12 if we don't allow multiattach - it should be pretty easy: only once consumer could access to the volume 16:24:34 True 16:24:38 * bswartz understands why multiattach makes people crazy 16:24:38 e0ne: Yeah, in that case it seems to mean whack all connections. 16:24:46 :-) 16:24:54 :) 16:25:07 So, do we fix this up to mean that now and then deal with multi-attach when we get there? 16:25:23 what about to allow force detach only if connection info is available? 16:25:28 Could disallow force detach on multi-attached volume? 16:25:40 That's the only sensible expectation I can think of for now. 16:25:50 jungleboyj: it's definitely an option 16:26:03 Either make connectory mandatory, or make sure we all know it means to remove all attachments. 16:26:14 so I'm forgetting what the new attach API looks like, but isn't there an ID that could be passed in rather than the whole connector? 16:26:47 bswartz: Yep, with the new workflow it just needs the ID. 16:26:47 smcginnis: +1. that what I proposed few lines earlier 16:27:15 it seems like we should require the connector then, to avoid confusion during multi attach situations 16:27:32 smcginnis, bswartz: and we get get connector info from the DB with that ID 16:27:38 it shouldn't be a big burden for API clients to obtain that ID 16:27:57 bswartz: Problem is we need to support old and new for now. 16:28:08 oh shite 16:28:17 damn backwards-compatibility 16:28:24 smcginnis: even swe must support all old APIs :( 16:28:34 bswartz: I think I actually lean toward not making it mandatory, and our expectation is we would need to remove all attachments if a force-detach is called without specifying which one. 16:29:12 smcginnis: I lean that way as well. 16:29:32 well for new versions, make it mandatory, and for older versions, pick any active attachment using some rule 16:29:50 that way people who don't use multiattach will have zero problems 16:30:13 and people who do use multiattach will be forced to use the newer API if they want sane behavior 16:30:17 bswartz: Well, I don't think we were originally looking at adding a new call for working with the new APIs. 16:30:24 bswartz: Just make the existing call work for either. 16:30:32 just microversion it 16:30:57 new mircoversion =! existing API 16:31:17 Microversions solve all the problems. :D 16:31:19 * bswartz looks confused 16:31:43 smcginnis: jgriffith would love if we did some more microversions. 16:31:47 the point of microversions is so you can change existing APIs... 16:31:51 smcginnis: and add new problems with them :) 16:31:58 For now, let's just assume no connector means to remove all attachments. 16:32:06 Multiattach or no multiattach. 16:32:07 jungleboyj: :) 16:32:20 smcginnis: +1 16:32:26 e0ne: Seeing if I poke enough he will show up. 16:32:28 if you lock yourself into a scheme where you can't change existing APIs then you have unsolvable problems like the one we're facing now 16:32:30 smcginnis: +1 16:32:33 And we'll see if we need to microversion a change on the API once we get closer to actually really supporting multiattach. 16:32:51 smcginnis: That makes the most sense to me. 16:32:54 bswartz: volumev4! 16:32:55 Hah 16:33:05 * jungleboyj sighs 16:33:10 * mdovgal is wonder when we will get anniversary 50th microversion is v3 api 16:33:24 mdovgal, lol :) 16:33:32 let's drop attach/detach things in microversion v.404 16:33:40 lol 16:34:08 OK, I'll send out a ML post to help communicate this decision. 16:34:12 manila is up to version 2.32 16:34:13 * bswartz ducks 16:34:32 #info force-detach without a connector provided should be handled by drivers by removing all attachements. 16:34:41 bswartz: We're almost there. 16:34:53 smcginnis: we have to update API ref too 16:34:54 mdovgal: Sounds like an opportunity for a party. 16:34:55 smcginnis: we will need microversion for multi-attach and I think by when we get there that can be the 50th anniversary time :) 16:34:59 #action smcginnis to communicate this decision on the ML 16:35:07 ildikov: Probably 16:35:18 e0ne: Right, that should be done right away too. 16:35:33 jungleboyj, i will put a pack of beer for this moment :D 16:35:34 ildikov: That will be something to celebrate! 16:35:40 #action smcginnis to update api-ref for force-detach to explicitly state this expected behavior. 16:36:01 #topic Open Discussion 16:36:10 smcginnis: weekly IRC meeting canceled next week? 16:36:11 Anything else? 16:37:05 jungleboyj: for sure :) 16:37:33 bswartz: Hah! 16:37:35 smcginnis: will we have something like mid-cycle meetup at the Summit? 16:38:01 e0ne: There are various Forum sessions, but more cross-project concerns. 16:38:06 Nothing really specific to Cinder. 16:38:13 But a bunch of us will be there. 16:38:43 So if there is anything that could benefit from some high bandwidth discussions, the bar^wconference hallway can work. 16:39:02 He he he. 16:39:26 We got more work done in the bar at the PTG than anywhere else. 16:40:09 There were some productive evening for sure. 16:40:15 smcginnis, thats what the hacking rooms are for 16:40:41 diablo_rojo: do the hacking rooms have booze too? 16:40:49 bswartz, if you bring it ;) 16:40:59 So, got dragged out for a bit. What was decided on the connector thing? 16:41:02 So nothing official for Cinder there, but let's definitely get together in the hacking rooms when free. 16:41:18 Swanson: Kill all attachments if it's called without specifying one. 16:41:35 @! 16:41:36 bswartz (╯°□°)╯︵ ┻━┻ 16:41:44 I knew that was coming. 16:42:10 hemna got the bot in the meeting room I see. :) 16:42:17 smcginnis, Ah. That sucks. 16:42:23 smcginnis: Yep. :-) 16:42:28 Swanson: +1 16:42:36 Swanson: Because you didn't listen to my advice in the first place? :) 16:43:28 smcginnis, Returning FC info might be fun. 16:44:01 Swanson: Returning what was removed from that call? 16:45:18 smcginnis, I'm raising. I don't care what all's y'all does. Yeah, that stuff. 16:45:49 :) 16:45:52 OK, anything else? 16:46:32 Oh, I'll just mention I disabled voting on the VMware CI. 16:46:45 So if anyone has any patches with that showing a -1, 16:46:56 That doesn't prevent it from being able to be merged, 16:47:04 smcginnis: great 16:47:15 smcginnis: thanks 16:47:15 smcginnis: Thanks. 16:47:15 But you may want to do a recheck on those if you want it to show up without a red -1 in the list of reviews. 16:47:19 smcginnis, Nice! Our long national nightmare is over. 16:47:33 Didn't realize it was something we had complete control over. :) 16:47:40 o/ 16:47:41 Thought it was a infra setting somewhere. 16:47:52 smcginnis: thanks! good news :) 16:47:57 Yep! 16:48:19 OK, before we go, just an open plea for anyone and everyone to do reviews. 16:48:27 I think our review numbers have really dwindled. 16:48:42 :-( 16:48:48 Just want to point out for any new folks just getting involved, non-core reviews are extremely helpful. 16:48:59 smcginnis: ++ 16:49:11 smcginnis: +1 on both notes 16:49:19 All the reviewers are off on shinny new clouds and/or containers? 16:49:21 Even if you don't feel like you know the code well, being able to have more eyes on patches to catch logic errors and things like that really does help. 16:49:35 smcginnis: low review activities could be caused be summit's preparation too 16:49:38 +1 smcginnis 16:49:42 Also, it is how you learn the project. 16:49:43 Even if you don't know the code you can always be pedantic about the style. 16:49:50 e0ne: True. 16:49:52 e0ne: I hope it does pick up after the summit. 16:49:59 Swanson: ;) 16:49:59 * jungleboyj just thought of another slide for on-boarding. 16:50:14 smcginnis: all of us hope 16:50:16 * jungleboyj needs to stop working on this prsentation 16:50:24 For those of you that used it, I have http://cinderstats-dellstorage.rhcloud.com/ updating again. 16:50:30 jungleboyj, spell check it one more time. 16:50:48 The Cinder Open Reviews link is useful to find reviews that have been sitting out there for a long time. 16:50:48 @b Swanson 16:50:59 @!b Swanson 16:50:59 jungleboyj (╯°□°)╯︵ ┻━┻ ︵ ╯(°□° ╯) Swanson 16:51:11 jungleboyj: good idea. you can start work on my slides now :) 16:51:13 ;) 16:51:22 And the Cinder Review Inbox link off our wiki is very helpful too: https://wiki.openstack.org/wiki/Cinder 16:51:38 e0ne: Hah! 16:51:50 smcginnis: could you please add brickclient-ext to http://cinderstats-dellstorage.rhcloud.com/? 16:51:51 smcginnis: Thanks for getting the stats updating again. 16:52:17 OK, safe travels to everyone. See you in Boston. 16:52:35 see you next week 16:52:43 :-) See you all next week! 16:52:51 Toodles. 16:53:07 #endmeeting