16:08:41 <smcginnis> #startmeeting Cinder
16:08:41 <openstack> Meeting started Wed Apr 13 16:08:41 2016 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:08:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:08:45 <openstack> The meeting name has been set to 'cinder'
16:08:51 <smcginnis> ntpttr: Thanks!
16:08:52 <Swanson> meetbot cometh
16:08:55 <smcginnis> #topic Announcements
16:08:55 <thingee> ditto
16:09:02 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/092104.html Midcycle planning
16:09:13 <diablo_rojo1> Who knew a bot could be so exciting?
16:09:16 <baumann> Am I supposed to say "hello" again now that it's start? :D
16:09:24 <baumann> started*
16:09:30 <smcginnis> I also have most of the schedule entered for the Summit:
16:09:37 <smcginnis> #link https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Cinder%3A+ Summit Cinder Track
16:09:48 <tbarron> baumann: i think you just did, even if it's quoted
16:10:07 <smcginnis> :)
16:10:15 <smcginnis> #link https://etherpad.openstack.org/p/newton-cinder-summit-ideas Planning etherpad
16:10:23 <jungleboyj> oh baumann
16:10:26 <smcginnis> Still add things to the etherpad if you think of additional topics.
16:10:43 <smcginnis> We have Friday to work through any smaller topics.
16:10:53 <dulek> smcginnis: Looks like we have one more working session left?
16:10:55 <smcginnis> There is also a work session on Thursday that I've kept open so far.
16:10:56 <diablo_rojo1> The summit app hasn't been working for me. Has anyone else tried it yet?
16:11:00 <smcginnis> dulek: Yep.
16:11:18 <smcginnis> Thinking of designating that an unconference like Nova does if we don't have a big enough topic to allocate to that.
16:11:23 <dulek> Last time we needed to vote which sessions go in, what happened this time?
16:11:25 <smcginnis> I'm sure we'll fill the time on something.
16:11:35 <smcginnis> I could just mark that as the "bikeshed" session. :)
16:11:46 <scottda> smcginnis: That unconference thing works well
16:11:49 <smcginnis> dulek: Oh, did we vote?
16:12:02 <smcginnis> scottda: I do like the idea.
16:12:04 <scottda> Lotsa stuff only takes 5-10 minutes to discuss
16:12:11 <dulek> smcginnis: At least there were more sessions than slots, so we've pushed a lot for Friday.
16:12:27 <smcginnis> dulek: Yeah, does seem like we had a lot more last time around.
16:12:39 <smcginnis> Not sure if that's good or bad. :)
16:12:58 <smcginnis> #topic NFS Snapshots Status
16:13:00 <smcginnis> eharney: Hey
16:13:04 <eharney> hey
16:13:12 <eharney> just wanted to give a general update / request for help here
16:13:26 <eharney> this feature is mostly there now, at least according to CI  (which is now in "check experimental")
16:13:51 <eharney> i suspect there are a few small things to hammer out still, and i don't have a ton of time budgeted for this
16:14:03 <eharney> so now is a good time for interested parties to help try it out and see how solid it looks
16:14:19 <smcginnis> eharney: It would be nice to get that working.
16:14:19 <eharney> oh yeah: https://review.openstack.org/#/c/147186/
16:14:30 <smcginnis> #llink https://review.openstack.org/#/c/147186/
16:14:37 <smcginnis> #link https://review.openstack.org/#/c/147186/
16:14:42 <xyang1> eharney: you still marked WIP
16:14:55 <eharney> for background, my current worry is that libvirt on Ubuntu trusty is kind of old and maybe missing some of the ideal-case code this uses
16:14:58 <eharney> xyang1: because of this ^
16:15:03 <eharney> WIP doesn't mean don't review it!
16:15:29 <eharney> so i'm going to try to figure out what's going on with trusty, but general checking would be helpful
16:15:36 <eharney> that's about it
16:15:42 <smcginnis> eharney: Thanks!
16:15:51 <smcginnis> #topic List manageable volumes and snapshots
16:15:56 <smcginnis> avishay: Hi
16:16:00 <avishay> Hey everyone
16:16:08 <avishay> I'm working on a feature that lists volumes and snapshots available for the 'manage-existing' APIs. Basically the driver will query the backend and return metadata regarding which volumes are available to manage.
16:16:15 <avishay> The spec is already merged and the code is up for review.
16:16:21 <avishay> #link https://review.openstack.org/#/c/285296
16:16:29 <avishay> There were two main issues brought up. The first, by Sean, is to move the manage-existing APIs from contrib to /v3. Thoughts?
16:16:54 <scottda> avishay: We want to move all extensions to core, and soon
16:16:56 <eharney> that sounds reasonable to me
16:17:03 <dulek> avishay: +1
16:17:05 <scottda> so that we can microversion changes...
16:17:13 <scottda> and because many of them should be in core.
16:17:16 <e0ne> should we move it to core as a new microversion?
16:17:26 <jungleboyj> avishay: Thanks for working on that.  A good add.
16:17:36 <scottda> e0ne: I don't think it needs a new microvesion
16:17:38 <avishay> Will there be no more extensions?
16:17:44 <DuncanT> avishay: +1 on moving to core
16:17:54 <DuncanT> scottda: It should be a microversion.... the API changed
16:18:02 <dulek> scottda: According to "do we need a new microversion" adding a new endpoint requires a microversion.
16:18:11 <e0ne> DuncanT: +1
16:18:17 <DuncanT> avishay: Nova have said no extensions at all. Their reasoning was fairly sound
16:18:20 <geguileo> DuncanT: +1
16:18:24 <scottda> DuncanT: OK, I need to review it.
16:18:26 <avishay> OK, sounds good
16:18:38 <e0ne> AFAIR, we add every new API as microversion
16:18:40 <avishay> smcginnis: according to what you saw, no microversion is necessary?
16:18:43 <geguileo> So new APIs should go to core and not to contrib?
16:18:51 <e0ne> #link http://docs.openstack.org/developer/cinder/devref/api_microversion_dev.html#when-do-i-need-a-new-microversion
16:18:52 <DuncanT> geguileo: Yes
16:19:00 <e0ne> geguileo: yes
16:19:00 <smcginnis> avishay: I thought according to the "do I need to microversion" decision tree it did not.
16:19:06 <smcginnis> But I could certainly be wrong.
16:19:14 <e0ne> we're gonig to migrate all extensions to microversions
16:19:16 <DuncanT> avishay: Microversion is for moving the API into core
16:19:18 <smcginnis> Still new enough I think we are figuring a little out as we go and learning.
16:19:21 * geguileo missed that announcement  :-(
16:19:39 <scottda> If we move the API to core, it would need a microversion
16:19:40 <avishay> smcginnis: yep
16:20:03 <avishay> OK I'll figure that all out and post a new version, thanks for that feedback all
16:20:24 <smcginnis> avishay: Thanks, I do think it's a good addition. Appreciate you working on it.
16:20:26 <avishay> The second issue, brought up by both DuncanT  and smcginnis has to do with the amount of data returned. The API doesn't support paging because the data about volumes on the backend is supplied by the driver querying the backend, and not from the DB as is usual.
16:20:35 <avishay> smcginnis: fo sho
16:20:47 <avishay> The best solution I can think of is to pass the sorting/paging parameters to the driver. If the backend supports this, great. If not, the driver can call a generic function to sort/page the metadata.
16:20:47 <DuncanT> avishay: The move to core should probably be a different patch to your addition
16:20:57 <avishay> Kind of ugly, but it could work. Thoughts?
16:21:01 <avishay> DuncanT: +1
16:21:08 <smcginnis> DuncanT: Well this is new, so I think right to core.
16:21:18 <DuncanT> avishay: bswartz  posted up some links to manilla's move-extensions-to-core in a previous meeting
16:21:27 <smcginnis> DuncanT: Or is there a reason to do an extension just to follow up and move it?
16:21:30 <erlon> avishay: what if you handle that in manager?
16:21:37 <avishay> smcginnis: this is a new action on an existing resource
16:21:46 <scottda> Yes, I'd like to get started on the move-to-core work, but might not be until after Austin
16:21:48 <erlon> avishay: I mean the manager does the paging no matter what the driver returns to it?
16:21:50 <DuncanT> smcginnis: Move the whole manage/unmanage to core
16:22:01 <thingee> yes I agree move it all to core.
16:22:09 <smcginnis> DuncanT, avishay: Ah, yeah, I see what you're saying.
16:22:14 <e0ne> scottda: +1
16:22:28 <avishay> erlon: because the driver may be able to ask for a subset of volumes from the backend, instead of asking for everything and having the manager throw part of it out
16:23:08 <avishay> I'm not sure what kind of APIs backends have to list volumes, specifically if paging is supported, that's why I wanted feedback from you all
16:23:23 <erlon> avishay: do you have an idia of how many drivers are able to do that?
16:23:25 <smcginnis> No paging from mine.
16:23:33 <avishay> erlon: no clue
16:23:47 <avishay> I also don't know how often we will have so many volumes that it becomes an issue
16:24:16 <avishay> But for the sake of robustness, we should think about this
16:24:17 <eharney> is it possible to do pagination in a way that won't be racy in this case?
16:24:18 <erlon> avishay: mhm. it looks to me that this wouldn't be an overhead
16:24:42 <avishay> eharney: racy how?
16:24:55 <eharney> avishay: contents on the backend changing between your calls for more pages
16:25:14 <erlon> avishay: also the drivers could do filter and still pass the reduced list  to manager, that could do the paging
16:25:24 <e0ne> eharney: good point
16:25:41 <erlon> avishay: if the driver does not do any previous filtering it would pass the whole list
16:25:46 <avishay> eharney: isn't it always racy in that way?  if you do list volumes on cinder with pagination, they are separate calls with no guarantee of no change between them, no?
16:26:06 <erlon> mine does no paging as well
16:26:08 <eharney> avishay: i guess that's true
16:26:55 <smcginnis> avishay: Cool, anything else for now?
16:27:10 <avishay> OK, so does it make sense to everyone that I will add a generic function to sort/page that drivers can call if they don't support it natively?
16:27:23 <avishay> DuncanT ?
16:27:36 <DuncanT> Seems reasonable, yes.
16:27:39 <smcginnis> avishay: +1
16:27:50 <DuncanT> Not great performance, but it keeps the API consistent
16:27:50 <avishay> OK cool, will work on those points - thanks all!
16:27:57 <smcginnis> avishay: Thanks
16:28:03 <smcginnis> #topic Cinderclient /v3 endpoint support
16:28:06 <smcginnis> scottda: Hey
16:28:08 <scottda> Hi
16:28:26 <scottda> I wanted to talk about the direction I'm taking with /v3 endpoint before the Summit..
16:28:33 <scottda> in case of controversy.
16:28:36 <scottda> #link https://review.openstack.org/#/c/300028
16:28:40 <e0ne> scottda: I've tested your patches on my env. nothing were broken
16:28:51 <scottda> I'm moving cinderclient /v2 stuff to /v3
16:28:55 <scottda> e0ne: Thanks!
16:29:04 <e0ne> but I still need review it more closer
16:29:08 <scottda> And then we can make changes only in one place
16:29:13 <geguileo> scottda: I've been testing this today
16:29:16 <smcginnis> scottda: So this is so the commonality between 2 and 3 is in one place, and both endpoints use the common code?
16:29:16 <scottda> Even if the change is on /v2 and /v3
16:29:22 <geguileo> scottda: And I don't think it's a good idea to default to v3
16:29:29 <scottda> smcginnis: Yes
16:29:31 <thingee> geguileo: +1
16:29:33 <smcginnis> scottda: +1
16:29:50 <scottda> api_version.wraps() will toggle based on microversion (or major version)
16:30:05 <e0ne> geguileo: +2. I remember how was painful switching to v2 last year
16:30:08 <scottda> #link https://review.openstack.org/#/c/301941/8/cinderclient/api_versions.py
16:30:18 <scottda> so, this is how Nova and Manila do it.
16:30:28 <geguileo> scottda: Then that's not working  ;-)
16:30:28 <smcginnis> +1 for consistency
16:30:41 <diablo_rojo> smcginnis: +1
16:30:43 <smcginnis> geguileo: You're not seeing that?
16:30:48 <geguileo> scottda: At least not like it does on the server side...
16:30:53 <scottda> geguileo: Do you mean my code defaults to v3?
16:30:59 <jungleboyj> e0ne: Horribly painful.
16:31:00 <geguileo> smcginnis: Maybe it's something specific to my patch...
16:31:12 <geguileo> scottda: I think so
16:31:32 <scottda> geguileo: OK, I'm fine with default to v2, but the code only needs to live in one place.
16:31:37 <geguileo> scottda: Let me do another test and I'll confirm
16:31:41 <e0ne> scottda: for the record: nova's approach coul not be the best
16:31:46 <scottda> geguileo: OK, thanks.
16:31:55 <geguileo> scottda: +1 to live only in 1 place
16:31:56 <jungleboyj> scottda: ++
16:32:08 <jungleboyj> I think we need to have a plan going forward to getting to v3 though.
16:32:17 <scottda> e0ne: Yes, and I'm open to any approach, I mainly want to figure out issues now, so we can discuss at Summit
16:32:23 <e0ne> jungleboyj: +1
16:32:40 <scottda> IF we don't add v3 endpoint support to cinderclient, we dont' get microversions
16:32:59 <scottda> And many things are queueing up behind this
16:33:09 <e0ne> scottda: I'm not saying that current approach is bad or no. I'm saying that we need to be careful coping nova's approach
16:33:17 <dulek> It looks like a lot of controversy. Do we have "microversions and V3 API - forward plan" session proposed?
16:33:32 <scottda> dulek: No, but we can
16:33:45 <scottda> But what is the controversy?
16:33:50 <smcginnis> We do have it as part of the "recap
16:33:52 <scottda> just when we change the default?
16:33:54 <smcginnis> session
16:34:00 <smcginnis> To make sure everyone is aware of it.
16:34:09 <geguileo> scottda: Confirmed, goes to v3: cinder service-list --> Vary: OpenStack-API-Version Openstack-Api-Version: volume 3.0
16:34:13 <dulek> smcginnis: I thought that geguileo proposed recap sessions as kind of tutorials for contributors.
16:34:15 <smcginnis> I broke that into two sessions assuming some will require some detailed discussion.
16:34:20 <scottda> cinderclient just needs support to use 'os-api-version 3'
16:34:28 <scottda> or 'os-api-version 3.1'
16:34:28 <smcginnis> dulek: Yes, but I'm sure it will cause more discussion.
16:34:36 <dulek> smcginnis: Agreed. :)
16:34:57 <DuncanT> I think getting a patch up that needs a switch to use v3 is a good start, let people test and get comfortable
16:35:03 <geguileo> scottda: Today, I've played around with it and made 5 patches that use microversions on top of your patches, and everything looks quite good
16:35:07 <scottda> geguileo: OK, I'll have a look. Might be broken :)
16:35:24 <jungleboyj> DuncanT: That sounds reasonable.
16:35:25 <scottda> geguileo: e0ne Thanks for the reviews and testing
16:35:42 <e0ne> scottda: thanks for working on it
16:35:47 <scottda> DuncanT: https://review.openstack.org/#/c/303627/5/cinderclient/v3/services.py
16:36:00 <scottda> #link https://review.openstack.org/#/c/303627/5/cinderclient/v3/shell.py
16:36:12 <scottda> There's a patch that uses this
16:36:38 <smcginnis> Related - ameade has this patch out there for devstack: https://review.openstack.org/#/c/300585/
16:36:49 <geguileo> Today I uploaded 5 more that use microversions
16:37:14 <e0ne> #link https://review.openstack.org/#/c/300585/
16:37:18 <geguileo> They are in the related changes of that patch
16:37:21 <scottda> And NOva-cinder changes for multi-attach will need this.
16:37:32 * dulek cannot keep up with geguileo's flow of patches. ;)
16:37:59 <scottda> So, some issues can come out during review (i.e. default should still be /v2)
16:38:19 <scottda> But it'd be good for opinionated persons to have a quick look before the Summit
16:38:27 <scottda> Else this will drag on.
16:38:28 <smcginnis> +1
16:38:29 <geguileo> scottda: Yeah, I have a couple of things that have come up during my patches
16:38:36 <geguileo> scottda: Will comment on your patches
16:38:43 <scottda> geguileo: Thank!
16:39:45 <smcginnis> #topic Open Discussion
16:39:50 <smcginnis> Open floor...
16:40:06 <diablo_rojo> The summit app doesn't work for me, anyone else tried it yet?
16:40:15 <diablo_rojo> I can't get signed in.
16:40:18 <DuncanT> diablo_rojo: Seems to do the basics
16:40:25 <thingee> who is ready for some two step at the summit?
16:40:25 <scottda> diablo_rojo: I could not sign in either
16:40:29 * thingee looks at DuncanT
16:40:29 <DuncanT> diablo_rojo: I'm certainly signed in
16:40:41 <DuncanT> thingee: sure
16:40:42 <ntpttr> diablo_rojo: yeah, it worked for me, but a friend of mine had an issue where they had their account settings to 'block forever'
16:40:58 <diablo_rojo> scottda: What error did you get?
16:41:07 <ntpttr> I guess when you sign in you can make some setting 'allow' or 'block' you when you try to sign in
16:41:16 <scottda> diablo_rojo: Could be me and password issues, so not sure. I've a new phone, so lotsa issues compounding...
16:41:20 <diablo_rojo> ntpttr: So there's a setting to change?
16:41:29 <smcginnis> Oh, speaking of the summit, kmartin had suggested this for a Cinder get together: http://easytigeraustin.com/
16:41:44 <smcginnis> We should try to do another informal meetup to get everyone out.
16:41:47 <diablo_rojo> scottda: it accepts my username and password, but then when it goes back to the app it dies
16:41:49 <ntpttr> diablo_rojo: yes, but I can't remember where off the top of my head.. he ran into it when trying to change his password on the website
16:41:50 <thingee> diablo_rojo: what does it say when you try to sign in?
16:42:04 <ntpttr> diablo_rojo: ah sounds like a different issue, he couldn't sign in at all
16:42:07 <smcginnis> diablo_rojo: You're on the blacklist.
16:42:23 <mc_nair> easy tiger is great - I like that idea
16:42:23 <baumann> smcginnis: Anything with a beer garden is a yes in my book
16:42:26 <diablo_rojo> thingee: It says "There was a problem performing this operation"
16:42:33 <smcginnis> mc_nair: You've been there?
16:42:35 <diablo_rojo> thingee: With a red x in a circle
16:42:38 <smcginnis> baumann: ;)
16:42:50 <karthikp> Hi guys, I have a patch please could somebody put their eyes on this and provide any suggestions: https://review.openstack.org/#/c/300708/.. Thanks!
16:42:54 <scottda> mc_nair: Is our local Austin expert!!
16:42:55 <dulek> smcginnis: Any idea for a date for informal meetup? Sunday like in Tokyo?
16:43:03 <diablo_rojo> smcginnis: I propose a float trip.
16:43:10 <smcginnis> :)
16:43:22 <smcginnis> dulek: Sunday would work for me. I get in around 4:30.
16:43:23 <e0ne> dulek: I'll arrive in Monday morning:(
16:43:34 <smcginnis> It is kind of nice doing it closer to the beginning.
16:43:36 <baumann> I propose a sleepover at mc_nair's apartment
16:43:40 <smcginnis> Hah!
16:43:41 <mc_nair> smcginnis: yes - good beer, good sandwiches and ping pong
16:43:52 <scottda> I've already got claim to mc_nair Balcony hammock
16:43:52 <kmartin> dulek, Sunday or Thursday or Friday?
16:43:53 <smcginnis> House party at mc_nair's!
16:43:55 <thingee> diablo_rojo: android?
16:44:00 <e0ne> Thursday
16:44:00 <diablo_rojo> thingee: Correct
16:44:03 <mc_nair> I have exactly one hammock and one couch but they are fair game
16:44:08 <dulek> kmartin: Some people may be out Friday evening.
16:44:12 <smcginnis> kmartin: When's the fancy schmancy HPE private party. We can make sure we do the same time again. :P
16:44:24 <ntpttr> I have one more question regarding moving all APIs to core - I have a patch that adds a new API and right now it's in contrib, should I move the new file to the v3 directory or v2? https://review.openstack.org/#/c/301444/
16:44:27 <jungleboyj> smcginnis: There is the Women of OpenStack event Sunday night.  Is there anything MOnday night?
16:44:29 <mc_nair> scottda: :) good decision
16:44:34 <dulek> e0ne: Thursday works for me I think. :)
16:44:45 <geguileo> ntpttr: v3
16:44:53 <ntpttr> geguileo: all right, thanks
16:44:54 <kmartin> smcginnis, Monday night(hpe only), Wednesday(core party)
16:45:01 <diablo_rojo> jungleboyj: Monday night is the booth crawl happy hour thing
16:45:02 <geguileo> ntpttr: And it should add a new microversion
16:45:09 <ntpttr> geguileo: yep its doing that already
16:45:12 <smcginnis> kmartin: Monday it is then. hehe
16:45:18 <geguileo> ntpttr: ok
16:45:23 <e0ne> :)
16:45:32 <kmartin> sure, be that way
16:45:58 <jungleboyj> diablo_rojo: Yeah, but the booth crawl doesn't usually go very long.
16:45:59 <smcginnis> kmartin: Hey, who do you want to hang out with? Coworkers or Cinder folks?
16:46:18 <smcginnis> diablo_rojo: That's the pregame.
16:46:25 <diablo_rojo> smcginnis: Got it.
16:46:26 <dulek> kmartin: Is HPE party invite-only, or something?
16:46:29 <kmartin> cinder folks of course
16:46:32 <e0ne> smcginnis, kmartin: or we can go to hpe party...
16:46:48 <diablo_rojo> kmartin: I can provide Cards against Humanity as an alternative to the HPE party.
16:46:56 <xyang1> kmartin: can we all crash the HPE party?:)
16:46:58 <smcginnis> e0ne: Yeah, kmartin, can you get us some fake badges or something?
16:47:05 <kmartin> hpe employee only
16:47:06 <diablo_rojo> xyang1: +1
16:47:21 <smcginnis> dulek: The main one does require RSVP, but I think they are just doing that to get a head count.
16:47:24 <jungleboyj> diablo_rojo: He he
16:47:56 <kmartin> I killed you guys last time with Cards against Humanity, did you work on your game? :)
16:48:05 <smcginnis> OK, we probably don't need this captured for prosperity. Thanks everyone!
16:48:08 <jungleboyj> kmARC: I have been practicing!
16:48:15 <smcginnis> #endmeeting