16:00:02 <smcginnis> #startmeeting Cinder
16:00:03 <openstack> Meeting started Wed Jan 25 16:00:02 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:04 <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 patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu jgregor baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell stevemar watanabe.isao,tommylikehu mdovgal ildikov
16:00:06 <openstack> The meeting name has been set to 'cinder'
16:00:12 <smcginnis> wxy viks ketonne
16:00:15 <mdovgal> hi
16:00:15 <e0ne> hi
16:00:16 <eharney> hi
16:00:18 <xyang> hi
16:00:18 <erlon> hey
16:00:19 <jungleboyj> Hello!
16:00:23 <dulek> o/
16:00:27 <geguileo> o/
16:00:47 <diablo_rojo_phon> Hello :)
16:00:47 <scottda> yo
16:01:02 <smcginnis> #topic Announcements
16:01:04 <smcginnis> The usual...
16:01:12 <smcginnis> #link https://etherpad.openstack.org/p/cinder-spec-review-tracking Review focus
16:01:20 <smcginnis> Client freeze is tomorrow.
16:01:29 <smcginnis> jgriffith: Are you around?
16:01:49 <smcginnis> Or anyone know the status of attach/detach in the client?
16:02:02 <ildikov> smcginnis: there are a few things that would need to be fixed there
16:02:14 <hemna> yough
16:02:20 <scottda> #link https://review.openstack.org/#/c/387716/
16:02:28 <scottda> That's client attach/detach ^^
16:02:28 <ildikov> smcginnis: I can upload a new patch set in case jgriffith is not around to do it
16:02:40 <ildikov> smcginnis: I will check with him
16:02:43 <smcginnis> scottda: Thanks. I was hoping I had the wrong link for that one given it's current state. ;)
16:02:50 <smcginnis> ildikov: Thank you!
16:03:01 <scottda> yeah, doesn't look like it will be ready tomorrow...
16:03:10 <ildikov> smcginnis: by when do you need the new version?
16:03:14 <scottda> But, that only matters if Nova were ready to use it, right?
16:03:20 <ildikov> smcginnis: besides yesterday :D
16:03:26 <scottda> smcginnis: WE can always release the client .
16:03:54 <smcginnis> ildikov, scottda: Client freeze for Ocata is tomorrow. But yeah, we can always release a new client as soon as the freeze is over.
16:03:57 <ildikov> scottda: true, although I need the updated version for testing anyway, more convenient than do it locally all the time
16:03:59 <smcginnis> So maybe not a big deal.
16:03:59 <erlon> smcginnis: eharney: what about the NFS patch do you think it can be ready until tomorrow?
16:04:20 <jgriffith> smcginnis I am now :)
16:04:27 <smcginnis> jgriffith: Morning!
16:04:32 <jgriffith> smcginnis hey
16:04:37 <hemna> I'm assuming the client work also works for the older attach scenario in case the newer client is talking to an older cinder
16:04:40 <jgriffith> smcginnis yeah, sorry about the client; I'll get that fixed up today
16:04:51 <smcginnis> jgriffith: Awesome
16:04:57 <jgriffith> hemna it *works* but needs a few things in terms of clean up
16:05:06 <hemna> rockin
16:05:11 <smcginnis> Cinder statement in general ^^
16:05:11 <e0ne> hemna: +1. we have to support both attach APIs for a while
16:05:16 <dulek> smcginnis: :D
16:05:21 <e0ne> smcginnis: lol
16:05:21 <ildikov> jgriffith: it mostly works :)
16:05:34 <jgriffith> ildikov emphasis on *mostly* :)
16:05:38 <smcginnis> :)
16:05:40 <erlon> * works for me *
16:05:48 <ildikov> jgriffith: reading my mind :)
16:05:50 <jgriffith> erlon in that case my work here is done
16:05:54 <hemna> lots of 3rd party CI's are failing today.....
16:06:07 <erlon> jgriffith: :)
16:06:09 <smcginnis> hemna: Not just today. :/
16:06:13 <ildikov> erlon: don't discourage people from work! ;)
16:06:17 <e0ne> hemna: I'm afraid not only today :(
16:06:24 <hemna> :(
16:06:32 <smcginnis> But we can talk more about that if we have time for open discussion.
16:06:38 <jgriffith> hemna yeah, I am looking at some of those the past few days, seeing issues with snapshot object has no id member, and a number of other weird things
16:06:49 <smcginnis> #info Need to register for the PTG if you have not already done so.
16:06:51 <eharney> erlon: i think we should land it
16:06:54 <smcginnis> #link http://www.openstack.org/ptg PTG info and registration
16:07:19 <diablo_rojo_phon> Less than 50 spots left I believe
16:07:20 <dulek> diablo_rojo_phon: Do you have an estimate how much rooms in reserved block are left?
16:07:24 <smcginnis> I heard registration was getting close to capacity. Please don't wait too long if you were holding off registering.
16:07:28 <smcginnis> diablo_rojo_phon: Thanks!
16:07:28 <dulek> diablo_rojo_phon: 41 actually.
16:07:32 <diablo_rojo_phon> Room block there is still a lot of space.
16:07:45 <smcginnis> #link https://etherpad.openstack.org/p/ATL-cinder-ptg-planning PTG topic planning
16:07:46 <dulek> diablo_rojo_phon: Awesome, my reservation can wait till tomorrow. :)
16:07:47 <diablo_rojo_phon> dulek thanks :)
16:07:56 <smcginnis> Whether attending in person or not, please add any topics to the etherpad.
16:08:00 <diablo_rojo_phon> dulek haha yes it can :)
16:08:02 <erlon> eharney: great, I asked geguileo to have a look, any other cores, if possible please give a look: https://review.openstack.org/#/c/147186/
16:08:19 <jungleboyj> diablo_rojo_phon, How bad on the rooms?
16:09:02 <diablo_rojo_phon> jungleboyj: as far as I know it's not a whole lot better than last week.
16:09:18 <smcginnis> #link https://www.openstack.org/summit/boston-2017/call-for-presentations/ Summit CFP
16:09:28 <smcginnis> A couple more weeks left on submitting presentation topics.
16:09:45 <smcginnis> That ends Feb 6 I believe.
16:09:50 <Swanson> PTG PUSHING OVERPRICED ROOMS ON US! GET A WINNEBAGO! SOGGY!
16:10:11 <Swanson> carry on
16:10:18 <smcginnis> Swanson: No Trump tweets in the meeting room! :)
16:10:24 <jungleboyj> diablo_rojo_phon, Ok, thanks.  I think I will be using my room.
16:10:30 <smcginnis> #topic Cinder in-tree tests running on tempest
16:10:36 <smcginnis> erlon: Hey
16:10:38 <hemna> Swanson, yup.  I just got a room directly with the hotel.  way cheaper
16:10:51 <erlon> smcginnis: hey
16:11:12 <erlon> so, I was discussing with oomichi, from QA about the in-tree tests
16:11:13 <erlon> https://review.openstack.org/#/c/410248/
16:11:26 <diablo_rojo_phon> jungleboyj: sweet :) Get your other Lenovo friends to do the same :)
16:11:31 <jgriffith> jungleboyj there's a nice park-bench across from the hotel with your name on it, just use that
16:11:37 <erlon> he is not a fan of changing the core jobs for adding our in-tree tests
16:12:10 <jgriffith> erlon any reasoning that he gave?
16:12:35 <erlon> just, remembering, the ideia was to have our intree tests running in all cinder related jobs so, any tests that we added in-tree would have the same weight of the temepst tests
16:12:35 <smcginnis> #link https://review.openstack.org/#/q/topic:run-intree-tests Patches related
16:12:42 <smcginnis> #link https://review.openstack.org/#/c/410248/ Run Cinder in-tree tests: neutron-full
16:13:07 <erlon> jgriffith: the reasoon is that the in-tree tets are not for official/core features in other projects
16:13:08 <jgriffith> smcginnis thanks
16:13:11 <eharney> do we run things like the neutron in-tree tests in our base cinder test jobs?
16:13:14 <jungleboyj> jgriffith, I have been to that hotel, no way I am going on a park bench.
16:13:24 <erlon> and that could interefer in the normal behaviour of the job
16:13:39 <dulek> erlon: Couldn't we template it a way that in-tree will run only in openstack/cinder?
16:13:58 <eharney> we don't have many in-tree tempest tests yet, so it seems to me we should just focus on enabling them for cinder jobs and worry about other project jobs later
16:14:01 <erlon> eharney: what do they do in neutron?
16:14:12 <smcginnis> dulek: I found with trying to get driverfixes/mitaka set up, the control over when/where to run tests is really... limited.
16:14:14 <eharney> no idea
16:14:24 <e0ne> eharney: +1
16:14:44 <smcginnis> I'd mainly like to make sure in-tree tests are being run by third party CI.
16:14:44 <erlon> dulek: I think its possible but that would require to change the shared jobs
16:15:12 <erlon> dulek: if you see the list, that neutron job is the only one that is shared among other projecs
16:15:33 <erlon> hmm, othe problem was that the neutron job is shared among other projects
16:16:09 <erlon> may be an option would be to leave it without the intree tests and change only the ones that are not shared
16:16:28 <smcginnis> erlon: Might be a good compromise.
16:17:08 <e0ne> erlon: can it bw configurable via some env variables or devstack config per project?
16:17:16 <e0ne> s/bw/be
16:17:22 <erlon> smcginnis: I believe that by default all CIs run the plugins
16:17:28 <erlon> smcginnis: have to check though
16:17:34 <jgriffith> I hate to mention this again; but I thought we were in fact going to focus on jobs that ran *just* cinder without anything else first?
16:17:47 <smcginnis> erlon: Third party? Not by default. They need to use the all_plugins target.
16:17:54 <jgriffith> not sure if that's the same thing eharney is pointing out or not
16:18:11 <jgriffith> or if I'm just missing the boat again here (which is quite possible)
16:18:23 <smcginnis> jgriffith: I think you are correct, that's what I remember talking about in FC.
16:18:23 <erlon> smcginnis: hmmm
16:19:00 <jgriffith> unit-->functional--->integration
16:19:06 <erlon> smcginnis: in the past thingee pratol the Cis checking eachone were running the 276 tests :)
16:19:29 <jgriffith> erlon seems like a fulfilling career :)
16:19:34 <erlon> smcginnis: so, that could be an option
16:19:46 <erlon> jgriffith: haha
16:20:18 <jgriffith> wonder if we could write a bot to do that sort of thing periodically rather than relying on a human which is valuable for other things
16:20:18 <scottda> +1 to erlon patrolling the CIs
16:20:36 <scottda> :)
16:20:37 <eharney> jgriffith: ooh, meta-CI to test CIs
16:20:44 <jgriffith> eharney :)
16:20:48 <erlon> smcginnis: scottda: haha, I would defenetelly automate that
16:20:49 <e0ne> jgriffith: fyi, https://review.openstack.org/#/c/348449/. I can't get it reviewed since September:(
16:21:11 <e0ne> jgriffith: it's about testing only cinder w/o backends or something else
16:21:18 <jgriffith> e0ne omg!  I'm sorry!!!
16:21:19 <erlon> scottda: smcginnis: but having the Cis running the in-tree tests would be very good
16:21:37 <hemna> e0ne, rebase?
16:21:49 <erlon> scottda: I can help with that
16:21:52 <e0ne> hemna: hm... not a bad idea... done
16:22:37 <smcginnis> erlon: So for now, hold off on those set of patches I think?
16:22:59 <erlon> smcginnis: I think only the neutron?
16:23:03 <erlon> scottda: which is share
16:23:27 <smcginnis> erlon: Sure
16:23:41 <erlon> smcginnis: the other ones are only used by cinder, so, ifwe decide to have then changed it will find less resistence
16:24:00 <smcginnis> erlon: OK, good. Anything else needed to discuss in the meeting for now?
16:24:08 <erlon> smcginnis: ok then, ill talk to then
16:24:17 <erlon> smcginnis: im fine
16:24:22 <smcginnis> erlon: Thank you.
16:24:27 <smcginnis> #topic Generating support matrix/report
16:24:47 <smcginnis> We have a couple porposed options for reporting what optional features are supported by drivers.
16:24:59 <smcginnis> One is to generate a table like we have now in our wiki.
16:25:06 <smcginnis> #link https://review.openstack.org/#/c/371169/ Feature matrix proposal
16:25:15 <smcginnis> The other approach is to add it to the driver list:
16:25:20 <smcginnis> #link https://review.openstack.org/403854 Replication patch
16:25:26 <smcginnis> #link https://review.openstack.org/404180 A/A support
16:25:30 <hemna> ugh ABC classes
16:25:32 <smcginnis> #link http://docs.openstack.org/developer/cinder/drivers.html
16:25:44 <smcginnis> I guess they are not really competing. We could do both.
16:25:56 <smcginnis> My only concern is that driver list already has a _lot_ of data.
16:25:59 <eharney> we're getting rid of the ABC classes.
16:26:03 <geguileo> smcginnis: I think we should do only one
16:26:04 <erlon> smcginnis: do you have an output sample of the first?
16:26:10 <jungleboyj> eharney, I think that was the case.
16:26:11 <erlon> eharney: +1
16:26:12 <geguileo> smcginnis: Otherwise one of them will be eventually out of date
16:26:13 <smcginnis> geguileo: +1 that would be my preference.
16:26:14 <hemna> if that patch lands we can't get rid of the ABC stuff :(
16:26:25 <jungleboyj> geguileo, +1.  Don't need duplication.
16:26:26 <geguileo> smcginnis: Or maybe even both be out of date
16:26:36 <smcginnis> hemna: No, it's slightly different using the interface work.
16:26:45 <erlon> good would be if there was a way to merge the sphinx concept with the data from the driver_list
16:26:48 <jungleboyj> If we are doing the driver matrix though, we need a better solution than we currently have.
16:26:51 <diablo_rojo_phon> geguileo: +1
16:27:01 <jungleboyj> Having something automatically updated would be good.
16:27:06 <geguileo> erlon: That sounds like a good ide
16:27:08 <geguileo> a
16:27:09 <hemna> smcginnis, the patch says it's using the ABC classes to determine the what features they support
16:27:26 <diablo_rojo_phon> jungleboyj: truth. Cause we suck at remembering to update things.
16:27:27 <smcginnis> hemna: Oh, which one?
16:27:36 <hemna> https://review.openstack.org/#/c/371169/
16:27:38 <jungleboyj> diablo_rojo_phon, ++
16:27:42 <xyang> smcginnis: I thought Nova has something to detect the driver feature too, is this first patch using a different approach?
16:28:06 <smcginnis> hemna: Oh, that's the interface stuff. It uses ABC, but it's not the ABC mess we are trying to get rid of.
16:28:24 <smcginnis> xyang: Yeah, nova does generate a table somewhere in a similar way.
16:28:32 <hemna> haven't looked at the code yet, but if that's the case he should remove any mention of ABC :)
16:28:35 <xyang> smcginnis: ok
16:28:38 <hemna> ABC is a 4 letter word
16:28:44 <jungleboyj> xyang, I think the one that generates the matrix is like what Nova is doing.
16:28:55 <smcginnis> hemna: ;)
16:28:57 <xyang> jungleboyj: thanks
16:29:01 <jungleboyj> hemna, ABCx
16:29:01 <erlon> smcginnis: and then we can release the matrix with the release notes
16:29:07 <smcginnis> hemna: At least the interfaces hide it.
16:29:22 <smcginnis> erlon: That's a good idea.
16:29:41 <diablo_rojo_phon> erlon: +1
16:29:43 <hemna> the general idea is good.  would be nice to have that matrix updated every release automagically
16:29:49 <e0ne> erlon: +1
16:29:53 <smcginnis> Unfortunately it looks like the patch for the matrix is old enough now that the output is gone, so can't see an example of what that looks like.
16:30:06 <hemna> pewp
16:30:31 <xyang> hemna: +1.  time to get rid of the manually created support matrix on wiki which is completely outdated
16:30:52 <smcginnis> So I was hoping to get a feel from the group if we wanted to go the matrix route or add info to the driver list. Or both. But hopefully one or the other.
16:31:12 <diablo_rojo_phon> My vote is matrix
16:31:26 <xyang> smcginnis: I like the idea of generating the matrix automatically
16:31:27 <erlon> my vote is the merge of both
16:31:42 <diablo_rojo_phon> xyang +1
16:31:48 <geguileo> smcginnis: I vote for Matrix
16:31:50 <erlon> sphinx + driver_list output
16:31:50 <jungleboyj> smcginnis, I do use the matrix frequently.  So, it makes sense to go that route.
16:32:31 <dulek> This matrix patch was based on how Nove exposes it. Consistency is good, so automated matrix makes total sense to me.
16:32:40 <erlon> smcginnis: is it possible to make the driver list to generate the supported/optional features of each driver?
16:32:52 <smcginnis> erlon: OK, option 3 - keep the driver list as is so it's easy to just see what drivers are available, and add another page that does something similar but lists all drivers with their supported functionality.
16:33:05 <smcginnis> erlon: That is what the two patches are proposing.
16:33:13 <jungleboyj> smcginnis, What is the existing driver list?
16:33:22 <smcginnis> jungleboyj: http://docs.openstack.org/developer/cinder/drivers.html
16:33:45 <xyang> smcginnis: looks like I didn't get what the first patch does:).  Does it show what features a particular driver support?
16:33:52 <smcginnis> I'd actually eventually like that published somewhere other than under "developer" documentation, but it's a start.
16:33:53 <geguileo> My patches were adding the HA A/A support and replication info
16:34:08 <geguileo> smcginnis: +1
16:34:11 <smcginnis> xyang: Yeah. I don't have an example of that output though.
16:34:12 <jungleboyj> smcginnis, Oh, thanks.  I didn't realize we had that.
16:34:21 <jungleboyj> That is automatically generated as well?
16:34:32 <smcginnis> jungleboyj: Yep.
16:34:43 <rajinir> Sorting is messed up in http://docs.openstack.org/developer/cinder/drivers.html
16:34:44 <xyang> smcginnis: so the output would be similar to this https://wiki.openstack.org/wiki/CinderSupportMatrix (which is outdated right not)?
16:34:47 <jungleboyj> Sweet.  Could we set that up to have a link to the more detailed matrix?
16:34:56 <smcginnis> jungleboyj: Can also run a script to get json output of driver information as well for custom scripting. Pretty handy.
16:34:59 <dulek> xyang: Yeah, it's similar.
16:35:16 <dulek> Here how it looks like in NOva: http://docs.openstack.org/developer/nova/support-matrix.html
16:35:23 <smcginnis> xyang: Similar. It had a little different grouping and layout, but basically that idea, but automatically generated.
16:35:26 <dulek> Cinder's version was very similar.
16:35:35 <xyang> smcginnis: excellent!
16:35:39 <smcginnis> dulek: +1 thanks!
16:36:13 <smcginnis> OK, it sounds like in general we want to go the matrix route. So we should get some attention on that first proposal.
16:36:17 <xyang> dulek: I like it!
16:36:26 <erlon> scottda: this nova matrix is pretty neat!
16:36:43 <jgriffith> Ask Neo how neat the matrix ends up being
16:36:54 <smcginnis> :)
16:36:54 <e0ne> :)
16:37:07 <jgriffith> oh wait... different matrix :)
16:37:11 <jungleboyj> So, I think having the matrix like Nova is good and keep the general list.  Add a link from the list to the matrix
16:37:27 <smcginnis> That's all from me - just wanted to bring that up.
16:37:35 <jungleboyj> The link shoud be a little blue pill for the link.
16:37:35 <smcginnis> jungleboyj: Link from one to the other would be good.
16:37:39 <erlon> smcginnis: how about the matrix dependency of ABC?
16:37:40 <smcginnis> Hah
16:37:59 <dulek> Oh, BTW - guy behind the matrix patch no longer works in Cinder, I think. karthikp_, can you confirm?
16:38:09 <smcginnis> It's the interface ABC's I think, so that is good. That's the way we want to go and get rid of the ABC inheritance in the drivers.
16:38:34 <karthikp_> dulek: thats right... But I could check with if he wants to continue with that work
16:38:55 <smcginnis> karthikp_: Thanks. We can pick up where he left off if he's not able to continue.
16:39:23 <karthikp_> smcginnis: Sure ..I will check with him
16:39:27 <smcginnis> #info We want to generate a driver support matrix like Nova has.
16:39:40 <smcginnis> #info Will pick up the patch to work toward that.
16:39:54 <smcginnis> #topic Different approaches for cinderclient extensions
16:40:02 <smcginnis> e0ne: Let's move on to this one then..
16:40:13 <e0ne> thanks, smcginnis
16:40:29 <e0ne> so, all info is available in meeting agenda
16:40:51 <e0ne> we've got different solutions for cinderclient extensions now:(
16:41:12 <e0ne> I'm trying to fix noauth support in cinderclient
16:41:42 <smcginnis> I think we have "in-tree" extensions, and out of tree (brick) extensions, right?
16:41:43 <e0ne> but current auth plugins implementation is totally broken
16:41:47 <geguileo> e0ne: I have a hack for that, but I think we should do a proper fix
16:41:54 <jgriffith> e0ne so personally; I would like to see us just move to a contrib directory model only
16:42:12 <smcginnis> jgriffith: So kill brick-ext and move that to contrib?
16:42:19 <e0ne> jgriffith: TBH, I'm ready to implement any working and general solution
16:42:21 <geguileo> e0ne: I think we should use the keystone entrypoints mechanism
16:42:36 <jgriffith> e0ne and I'd like it to be such that we don't care if it's in tree or out (ie people can load extensions into the contrib directory on their own afer the fact)
16:42:45 <jgriffith> otherwise, they're not really useful IMO
16:42:51 <e0ne> geguileo: I don't get your point about keystone entry points
16:43:20 <geguileo> e0ne: I think keystone client has a mechanism for different auths
16:43:38 <geguileo> e0ne: Other projects like gnocchi are using it
16:43:38 <e0ne> jgriffith: but what soulution should be used? stevedore or just import module like brickclient-ext works?
16:43:53 <jgriffith> geguileo that hasn't worked out really well for us in the past, might be better now but something to consider
16:44:12 <e0ne> geguileo: noauth is onlly one use-case of extensions
16:44:15 <geguileo> jgriffith: I looked at our current code in there and it's a mess
16:44:18 <jgriffith> e0ne Personally I prefer the "just import everything" in the dir
16:44:27 <geguileo> e0ne: Yeah, that's why I propose the keystone way
16:44:28 <smcginnis> #link https://bugs.launchpad.net/python-cinderclient/+bug/1657156 Noauth bug
16:44:28 <openstack> Launchpad bug 1657156 in python-cinderclient "cinderclient does not support noauth" [Undecided,Confirmed] - Assigned to Ivan Kolodyazhny (e0ne)
16:44:32 <geguileo> e0ne: Because it solves a lot more cases
16:44:38 <e0ne> jgriffith: +1 it's not complicated and works well
16:44:38 <jgriffith> e0ne and provide a config mechanism to enable/disable by tenant or role
16:45:00 <jgriffith> geguileo yeah it's not pretty
16:45:08 <geguileo> jgriffith: And it cannot be extended
16:45:10 <smcginnis> IIRC, there were some different requirements with brick-ext that was a reason to make it a separately installable extension.
16:45:17 <jgriffith> geguileo and I know you could/would fix it up, but i'm not sure it's a good use of your time frankly
16:45:19 <geguileo> And everything is ad-hoc
16:45:25 <e0ne> jgriffith: looks like I have to write a spec for it
16:45:50 <jgriffith> geguileo oh, wait... we might be talking two things :)
16:45:53 <scottda> smcginnis: I think that was because of openstack client...
16:46:11 <geguileo> I just pushed my hack to support noauth: https://review.openstack.org/425277
16:46:12 <smcginnis> scottda: Hmm, I thought that was before we really started talking about osc.
16:46:24 <smcginnis> But that does bring a whole set of concerns as well.
16:46:32 <scottda> smcginnis: Having brick-ext separate was to facilitate moving cinderclient functionality to OSC
16:46:42 <bswartz> geguileo: +1
16:46:48 <smcginnis> scottda: Oh, OK.
16:46:53 <e0ne> #link https://review.openstack.org/425277
16:47:25 <e0ne> did we agreed to have in-tree extensions in a conrtib directory?
16:47:43 <smcginnis> e0ne: That sounds good to me.
16:47:49 <e0ne> great!
16:48:16 <geguileo> If we want to move to OSC, maybe we should just go with a hack for noauth and forget about extensions and stuff...
16:48:38 <scottda> geguileo: I'm not sure we want to move this to OSC...
16:48:40 <hemna> is OSC going to allow cinder specific extensions ?
16:48:45 <e0ne> geguileo: no, because OSC can use cinderclient extensions too
16:48:47 <hemna> like brick-ext
16:48:53 <scottda> geguileo: I think the evolution of this was to someday have stand-alone Cinder
16:49:07 <scottda> geguileo: With no dependency on Nova nor Keystone.
16:49:09 <smcginnis> hemna: I think that needs to be figured out yet.
16:49:14 <geguileo> e0ne: Sure, but if osc supports keystone auth extensions we can do noauth easily
16:49:26 <scottda> In which case, we don't necessarily want OSC dependency.
16:49:33 <geguileo> scottda: You can do standalone cinder with openstack client
16:49:45 <e0ne> geguileo: I'm talking about cinderclient extensions in general, not anly about noauth
16:49:45 <scottda> geguileo: Sure
16:49:49 <geguileo> scottda: You just use the right auth and it should work
16:49:53 <hemna> geguileo, osc can do noauth?
16:49:55 <jgriffith> scottda plan for the future, some day cinderclient goes away and there is only osc
16:50:11 <geguileo> hemna: probably
16:50:14 <hemna> lol
16:50:23 <geguileo> hemna: using keystone auth plugin mechanism
16:50:24 <scottda> ok, it seems that there were some issues around how OSC dealt with all this that was  why we are down that path..
16:50:29 <e0ne> jgriffith, scottda: cinderclient CLI. cinderclient will be available
16:50:45 <smcginnis> e0ne: +1 important distinction
16:50:52 <geguileo> So what I'm hearing here is that we'll never move to OSC
16:51:03 <scottda> no, I'm not saying that.
16:51:05 <bswartz> my dream is that cinderclient never goes away
16:51:07 <geguileo> I'm fine with that, but then it makes sense to properly fix our client
16:51:23 <e0ne> and cinderclient extenstion could provide both new Python and CLI APIs
16:51:29 <scottda> I'm saying that there were issues when we first added brick-ext.
16:51:42 <smcginnis> geguileo: We're not going to only osc anywhere in the short term, so I thing we need to make sure our client is good.
16:51:43 <jgriffith> e0ne true
16:51:57 <scottda> But I'm not certain I can articulate the issues. They were not my personal issues.
16:52:10 <geguileo> smcginnis: OK, then we need a big refactor in cinderclient/shell.py
16:52:11 <e0ne> I didn't find any cinderclient extension on pypi
16:52:28 <scottda> geguileo: +1 to cleaning up the client
16:52:33 <scottda> and shell
16:52:34 <e0ne> but there are some for novaclient
16:53:05 <e0ne> scottda, geguileo: +1. I working on it during  this release
16:53:25 <scottda> e0ne yes, thanks for that.
16:53:26 <e0ne> #link example of novaclient extensions https://pypi.python.org/pypi?%3Aaction=search&term=novaclient&submit=search
16:53:33 <e0ne> scottda: thanks for reviews
16:53:59 <smcginnis> 7 minutes left...
16:54:06 <geguileo> Here is what I was talking about the keystone auth plugin: http://docs.openstack.org/developer/python-gnocchiclient/shell.html
16:54:25 <e0ne> smcginnis: we can  switch to the next topic
16:54:27 <geguileo> You can see there that using that we could do noauth and all available auths in keystone
16:54:36 <e0ne> #link http://docs.openstack.org/developer/python-gnocchiclient/shell.html
16:54:39 <smcginnis> e0ne: Thanks
16:54:45 <smcginnis> #topic Snapshot-manage imports snapshots with wrong size
16:54:51 <smcginnis> mdovgal: You're up.
16:54:52 <mdovgal> yes
16:54:56 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/110493.html
16:55:02 <smcginnis> #link https://bugs.launchpad.net/cinder/+bug/1623596
16:55:02 <openstack> Launchpad bug 1623596 in Cinder "snapshot-manage imports snapshots with wrong size" [Undecided,Confirmed] - Assigned to Michael Dovgal (mdovgal)
16:55:03 <e0ne> geguileo: thanks. I'll take a look on it and your workaround later tonight
16:55:39 <mdovgal> we have the problem that in snapshot db table the size column is called volume_size
16:56:01 <e0ne> for note: I prefer option #2
16:56:15 <erlon> mdovgal: Im fine with the name,, because it 'was' the volume_size at the time the snapshot was taken
16:56:18 <mdovgal> in my letter i wrote about the problem and the way who we can solve the bug
16:56:35 <eharney> i'm not sure this is a "bug" on all drivers -- doesn't the right behavior here depend on backend implementation?
16:56:51 <mdovgal> yes. but at the time when we manage the snapshot using snapshot-manage command it isn't the volume size
16:57:09 <erlon> mdovgal: as a snapshot is a point in time representation, its implicit that the volume_size was reffering to the time it was taken
16:58:03 <erlon> eharney: the backend inplementaion just returns the size the snapshot have
16:58:13 <e0ne> eharney: here is how we set size https://github.com/openstack/cinder/blob/02389a1d2ac4822d37b1f7fbd29391097bfcb56f/cinder/volume/flows/manager/manage_existing_snapshot.py#L241 during snapshot_manage call
16:58:13 <mdovgal> and because of it we have incorrect manage result
16:58:46 <eharney> why is it incorrect?
16:58:57 <mdovgal> we will have current volume size, but not real snapshot. real snapshot size will be ignored
16:59:09 <mdovgal> e0ne, thanks for the link
16:59:12 <smcginnis> 1 minute warning
16:59:13 <erlon> eharney: ibeleive  the problem is only the interpretation that volume_size can lead
16:59:13 <eharney> ahh i get it, was reading wrong
16:59:17 <e0ne> eharney: snapshot object doesn't have 'size' attribute
16:59:45 <e0ne> mdovgal: np
16:59:49 <erlon> mdovgal: if you create a volume from the snapshot will it have the worng size?
17:00:03 <jungleboyj> Just a last second plug for anyone in the RTP area that some of us are meeting at Lonerider Brewery at 7:30 tonight:  http://www.loneriderbeer.com/  Join us if you can!
17:00:12 <mdovgal> erlon, hm... good question)
17:00:17 <smcginnis> mdovgal: Sorry, we're out of time.
17:00:21 * jgriffith fires up his private jet
17:00:24 <smcginnis> Maybe we can continue in the cinder channel.
17:00:29 <jungleboyj> jgriffith, Come on out!
17:00:29 <erlon> mdovgal: let discuss that in cinder
17:00:31 <mdovgal> yes. i  think we can
17:00:32 <smcginnis> jgriffith: Hah! Pick me up on the way.
17:00:38 <smcginnis> Thanks everyone.
17:00:39 <jungleboyj> smcginnis, ++
17:00:42 <jungleboyj> Thanks!
17:00:44 <smcginnis> #endmeeting