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