16:02:30 <jgriffith> #startmeeting cinder
16:02:30 <openstack> Meeting started Wed Sep 10 16:02:30 2014 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:34 <openstack> The meeting name has been set to 'cinder'
16:02:37 <jungleboyj> o/
16:02:43 <thingee> o/
16:02:51 <DuncanT> Hey
16:02:52 <tbarron> hi
16:02:56 <jgriffith> #agenda https://wiki.openstack.org/wiki/CinderMeetings
16:03:03 <avishay> hello all
16:03:12 <jgriffith> bswartz: you here?
16:03:19 <bswartz> yes
16:03:33 <jgriffith> #topic manage/unmage non-interger sized vols
16:03:38 <jgriffith> interesting problem :)
16:03:46 <bswartz> A question came up at a meeting today about what happens when I 'cinder manage' a LUN that's 1.5GB
16:03:47 <bswartz> We tell the user that the resulting volume is 2GB, but we don't resize it
16:04:02 <bswartz> so I can see bad things happening
16:04:20 <jgriffith> bswartz: at least some confusion if nothing else
16:04:43 <avishay> bswartz: what kind of bad things?  and why not resize?
16:04:47 <flip214> why is GB the default unit? test VMs might even work with half a gig.
16:04:48 <jgriffith> bswartz: problem is I don't want to go down the path of introducing floats to cinder volume sizes
16:04:54 <bswartz> as an aside -- I think non-integer-size volumes would be a good thing to support
16:05:01 <flip214> of course, production machines are likely to be much bigger
16:05:02 <jgriffith> flip214: you can easily test with smaller
16:05:10 <bswartz> but if we don't, then we need to do something about this manage use case
16:05:17 <jgriffith> flip214: problem is actually "int"
16:05:38 <jgriffith> bswartz: yeah.... my intial thought was resize
16:05:41 <jgriffith> bswartz: OR
16:05:42 <bswartz> the most obvious thing is to force a resize as part of the manage operation
16:06:00 <jgriffith> bswartz: document that hey... in the case of managing an existing vol we're going to fudge a bit
16:06:13 <DuncanT> There's no real harm in fudging I don't think...
16:06:16 <hemna> mep
16:06:31 <jgriffith> DuncanT: I'm leaning that direction as well... but I would say we should document it well
16:06:32 <avishay> i don't think we should resize automatically - the user might want to leave their volume as-is
16:06:33 <eharney> i don't see why we shouldn't just do a resize as part of manage as bswartz says
16:06:34 <DuncanT> Forcing a resize is going to be less popular
16:06:34 <bswartz> the problem is that tha manage operation is done by an admin -- the user doesn't know it happened
16:06:36 <jgriffith> DuncanT: maybe even in the help
16:06:42 <bswartz> the user can only see the size that cinder says it is
16:06:42 <jgriffith> avishay: +1
16:06:46 <flip214> jgriffith: just out of interest, why not floats? interoperability with drivers, upgrade path, ...?
16:06:56 <eharney> avishay: fair point
16:06:58 <jgriffith> flip214: because everything is designed and setup with ints
16:06:59 <DuncanT> jgriffith: +1 on documenting
16:07:08 <jgriffith> flip214: and it would flat out suck to try and change that everywhere :)
16:07:14 <flip214> jgriffith: ack.
16:07:19 <hemna> resizing an existing volume just to make the cinder db happy seems...hackish
16:07:26 <navneet> jgriffith: we may extend manage further with a flag for resize if required
16:07:29 <AlkaD_> +1 documenting
16:07:51 <navneet> jgriffith: degaut behavior remains as is
16:07:54 <DuncanT> Resizing the volume might also fail, e.g. a full array... refusing to import in that case is a bit weak
16:07:55 <jgriffith> navneet: I suppose that might be reasonable, but now I'm questioning how big of a deal this is
16:07:55 <jungleboyj> +1 Documenting.
16:08:04 <flip214> +1 documentation
16:08:22 <navneet> jgriffith: not so big but a slight confusion
16:08:27 <bswartz> that's all I had on this topic -- just wanted to raise the issue
16:08:30 <jgriffith> navneet: yeah
16:08:36 <jgriffith> bswartz: good point
16:08:41 <dustins> +1, as long as it's documented it ought to be alright
16:08:44 <avishay> i agree, just document
16:08:48 <DuncanT> It risks being another weird option that sees little to no testing and breaks without anybody noticing
16:08:49 <jgriffith> bswartz: I think we should start with the documenation aspect of it and go from there
16:09:09 <joa> ah. Was on the wrong chann >.< Hi o/
16:09:11 <jgriffith> DuncanT: +1
16:09:20 <DuncanT> You can even put the doc in it the http response too, no harm in that
16:09:22 <akerr_> so what about when your array is full of 1.1g volumes, all reporting 2g now.  You have a lot of wasted space there
16:09:25 <jgriffith> we're already getting to the point of having too many useless options
16:09:37 <jgriffith> DuncanT: yeah, I was thinking in the cinderclient manage help
16:09:40 <DuncanT> akerr: No wasted space at all
16:09:43 <jgriffith> but either way
16:09:59 <jgriffith> akerr_: yeah... why would you have "wasted" space?
16:10:01 <DuncanT> akerr: Since the array reports how full it is
16:10:08 <jgriffith> akerr_: or do you mean wasted quota?
16:10:17 <jgriffith> akerr_: thems the breaks IMO :)
16:10:26 <kmartin> akerr_: update stats will still report the correct number
16:10:26 <jgriffith> errr... "brakes"
16:10:33 <navneet> jgriffith: yeah wasted quota is good point
16:10:40 <DuncanT> The wasted quota is just tough luck... import is an edge case
16:10:50 <guitarzan> isn't manage supposed to be an exceptional case anyway?
16:10:55 <akerr_> ok, I wasn't thinking about the stat update being deoupled from the volume size report
16:10:57 <jgriffith> guitarzan: +1
16:11:06 <avishay> guitarzan: +1
16:11:13 <jgriffith> So here's the thing
16:11:18 <jgriffith> this is an admin's deal
16:11:27 <jgriffith> if he/she wants to match up things that's their choice
16:11:32 <avishay> if for some reason you have a system where manage is the norm, the admin can give out a little extra quota to cover it
16:11:35 <navneet> guitarzan: its exceptional but if somebody scripts to bring all their volumes using manage
16:11:35 <jgriffith> if he/she doesn't that's their choice as well
16:11:52 <jgriffith> navneet: *somebody* shouldn't be doing that, and admin maybe
16:11:55 <guitarzan> navneet: that person sets the quotas too
16:12:02 <navneet> guitarzan: and every volume is like 2.1 or 3.1 gb then you have exhausted your quota to gr8 extent
16:12:06 <jgriffith> navneet: and the quota thing isn't enough of an issue to make me care
16:12:18 <avishay> quotas are broken anyway :P
16:12:19 <guitarzan> navneet: so raise that users quota
16:12:25 <jgriffith> avishay: +1 :(
16:12:37 <navneet> guitarzan: customers have to pay for it right
16:12:42 <avishay> but yea, the admin can just give 1-2GB extra to cover the loss, no big deal IMO
16:12:49 <jgriffith> Ok, I think that it's a good point to be cognisant of
16:12:56 <guitarzan> navneet: you set up billing however you like
16:13:03 <DuncanT> navneet: Then fix your charging model... import is an edge case
16:13:08 <jgriffith> but I don't think it warrants a drastic change to the Cinder code
16:13:19 <jgriffith> Let's just note the implications here and leave it at that
16:13:24 <guitarzan> maybe someone will push hard enough to get float volume sizes, but that's a totally different situation
16:13:25 <AlkaD_> +1
16:13:29 <guitarzan> indeed
16:13:31 <rhe00> how hard would it be to limit the ui to not allow floats?
16:13:34 <jgriffith> guitarzan: ewwww
16:13:39 <navneet> DuncanT: ok...some food for thought
16:13:41 <guitarzan> jgriffith: just saying :)
16:13:59 <jgriffith> guitarzan: yeah, but now somebody is going to propose the 3K line patch that does it :)
16:14:03 <DuncanT> rhe00: Getting floats past me hitting -2 would be quite a challenge
16:14:09 <jgriffith> guitarzan: you mentioned the elephant in the room
16:14:10 <jgriffith> :)
16:14:13 <guitarzan> jgriffith: DuncanT has us covered
16:14:18 <jgriffith> guitarzan: _1
16:14:21 <jgriffith> errr
16:14:23 <jungleboyj> :-)
16:14:23 <jgriffith> DuncanT: +1
16:14:28 <bswartz> DuncanT: lol
16:14:37 <jgriffith> Ok... shall we continue?
16:14:42 <bswartz> yes, this topic is wrapped
16:14:46 <DuncanT> Let's.
16:14:46 <jgriffith> eharney: ready?
16:14:49 <eharney> yes
16:14:58 * jungleboyj pictures DuncanT hitting -2 with extreme prejudice
16:14:59 <jgriffith> #topic remove hard dep on profiler
16:15:09 <bswartz> DuncanT needs a -3
16:15:10 <eharney> alright i seem to have stirred up something here, let me explain this
16:15:13 <jgriffith> LOL
16:15:25 <eharney> this is a code implementation issue, not about changing the extent to which osprofiler is "part" of Cinder etc
16:15:27 <jungleboyj> bswartz: +3
16:15:34 <hemna> I think eharney's patch is a good way to go.  make this optional.
16:15:42 <eharney> my opinion is that a deployer should be able to run cinder-api and cinder-volume without having to install a profiling tool
16:15:48 <rushiagr> o/
16:15:52 <hemna> eharney, +1
16:16:13 <eharney> and i haven't yet heard a justification as to why doing it as it is done today is really needed
16:16:27 * DuncanT thinks installing everything gives a far, far, far better user experience
16:16:32 <jgriffith> eharney: IIRC the biggest reason is to make sure it gets tested in gate
16:16:43 <eharney> DuncanT: jgriffith: it's still in requirements.txt
16:16:43 <jgriffith> eharney: getting "one-offs" in gate code is *hard*
16:16:45 <eharney> so those do not change
16:16:47 <avishay> DuncanT: +1
16:16:54 <DuncanT> Making it optional severely limits how we can extend it in future
16:16:56 <hemna> jgriffith, but the testing in gate will happen if it's installed.
16:17:05 <hemna> according to eharney's patch
16:17:05 <eharney> DuncanT: how?
16:17:07 <jgriffith> eharney: oh... wait, then I'm confused *again*
16:17:19 <eharney> the patch lets cinder services run without it
16:17:23 <eharney> they attempt to load it by default still
16:17:32 <eharney> it is still present by default because it is still listed as a requirement
16:17:36 <eharney> behavior does not change
16:17:42 <DuncanT> eharney: If deployers ignore requirements.txt then it doesn't matter that it is in there, if they don't then there is no need to make it optional
16:18:11 <eharney> it matters for other reasons
16:18:16 <DuncanT> eharney: If it isn't there out of the box on every installation, then we can't easily ask people to turn it on the debug issues
16:18:28 <eharney> we are assuming that we merge this in Juno and then when osprofiler hits 0.9 the API doesn't change and break stable/juno
16:18:39 <joa> DuncanT: I dont really knowthis profiling code, but isnt there a configurable way to disable it and have passthrough-like functionnality ?
16:18:46 <eharney> DuncanT: i wasn't aware we were far enough along to be thinking about that
16:19:04 <DuncanT> joa: You can configure it off, yes, but currently you still need it installed
16:19:22 <DuncanT> eharney: I think we are, and we should continue with that mentality
16:19:29 <eharney> i just can't see the benefit of tying it so tightly into the middle of cinder
16:19:40 <DuncanT> eharney: If you make it optional now, any future patch to change that becomes a fight
16:20:00 * jgriffith wishes zul or some other pkg maintainer was about
16:20:00 <DuncanT> eharney: It isn't tightly coupled, it is just a requirement for it to be there
16:20:17 <hemna> DuncanT, isn't that the same thing?
16:20:21 <eharney> jgriffith: well, i do packaging for Fedora/RDO/RHOS...
16:20:27 <eharney> but i've kinda stated my POV
16:20:28 * DuncanT is a package maintainer, FWIW, even though we're a fairly damn specialised distro
16:20:36 * joa thinks profiling tools are too useful to be seen as hindrances...
16:20:40 <jgriffith> eharney: yeah... I wanted another doctors opinion so to speak
16:20:49 <hemna> any other distro mx will have to now build a package for osprofiler to just install and run cinder.
16:20:51 <jgriffith> eharney: not because I don't like yours, because I like more info :)
16:21:01 <eharney> nothing about this is about bashing osprofiler or making it less important
16:21:03 <jgriffith> I'm still unclear on the big issue with it
16:21:03 <avishay> jgriffith: as a doctor, i agree with DuncanT :)
16:21:15 <eharney> i think the current impl is architecturally flawed
16:21:16 <jgriffith> eharney: understood, I wasn't implying that at all
16:21:19 <jgriffith> sorry if I did
16:21:20 <eharney> i know
16:21:23 <DuncanT> What gain does making it optional provide?
16:21:32 <eharney> DuncanT: what hemna said for one
16:21:32 <DuncanT> What is the win? I know the cost
16:21:41 <hemna> I see this as being the same issues as requiring a 3rd party driver library installed just to run cinder :P
16:21:43 <thingee> From a deployer POV, I think it should be off by default. It's really annoying to find what to turn off to get better performance from OpenStack services. We already know we're all good documenting things clearly.
16:22:00 <jgriffith> thingee: I'm fine with that too....
16:22:06 <eharney> thingee: well it is off by default so let's not confuse things
16:22:11 <jgriffith> I think the default off/on thing is a different debate though no?
16:22:11 <navneet> hemna: have we stopped doing like this for 3par?
16:22:14 <eharney> but you have to install it and its reqs etc
16:22:16 * thingee is peachy then
16:22:19 <thingee> :)
16:22:26 <DuncanT> Any packager needs to be keeping up with loads of libraries, one more makes no real difference
16:22:31 <DuncanT> I've got ~40 on my list
16:23:03 <jgriffith> DuncanT: I don't know that "my life sucks, who cares if it sucks a little more" is a good arg
16:23:11 <hemna> :P
16:23:11 <eharney> it doesn't make a real difference as long as it doesn't have issues that trigger security audits or API breakages or dependency problems etc
16:23:12 <jgriffith> :)
16:23:20 <thingee> eharney: throw it in test-requirements.txt then?
16:23:21 <eharney> jgriffith: yeah.... packaging and such is always easy until it's not..
16:23:37 * jgriffith is thankful he doesn't have to do it
16:23:38 <DuncanT> jgriffith: *Any* openstack packager needs to be packaging all the new versions in requirements.txt - what difference does one more make?
16:23:38 <eharney> thingee: not sure what you mean
16:24:01 <jungleboyj> jgriffith: +2
16:24:06 <thingee> eharney: https://github.com/openstack/cinder/blob/master/test-requirements.txt
16:24:16 <eharney> thingee: it's in requirements.txt now
16:24:25 <eharney> i'm not even trying to remove it from there
16:24:32 <DuncanT> eharney: You can say that about every other package too... and oslo.db and oslo.rpc *have* triggered security audits
16:24:32 <hemna> DuncanT, I'm not sure that's a valid justification for not making this optional.
16:24:46 <eharney> DuncanT: yes but those provide things that i have to have for Cinder to _work_
16:24:49 <eharney> DuncanT: this does not
16:24:53 <thingee> eharney: was just thinking of avoiding it being installed for production cases.
16:24:56 <eharney> Cinder has to talk to a database
16:24:57 <DuncanT> hemna: It entirely negates the case for making it optional
16:24:58 <hemna> eharney, +1
16:25:02 <eharney> Cinder does not have to have a profiling tool to run
16:25:17 <hemna> eharney, heh, it does right now.  :(
16:25:27 <thingee> eharney: right, so hence my suggestion of test-requirements.txt
16:25:28 <hemna> until your patch lands that is.
16:25:32 <guitarzan> I'm not sure you'd want to have to deploy something else just to flip on profiling when something starts to get slow
16:25:39 <eharney> https://review.openstack.org/#/c/120455/ fixes this issue
16:25:45 <eharney> thingee: we can do that after this patch ^
16:25:57 <eharney> thingee: not possible now
16:26:04 <DuncanT> eharney: My big worry is that we find some cool new thing we can usefully profile, but that the code to make it optional gets more and more complicated
16:26:05 <avishay> guitarzan: +1, but the question is if we need to prevent people from shooting themselves in the foot?
16:26:18 <guitarzan> avishay: I don't see the bullets
16:26:21 <navneet> guitarzan: +1 profiling tool should be operators choice
16:26:33 <eharney> guitarzan: IMO that is up to deployers and packagers to work out as they do with all similar questions currently
16:26:37 <hemna> navneet, +1
16:26:40 <eharney> guitarzan: unfortunately here they have no option
16:26:40 <DuncanT> eharney: I'd rather see a proper plugin witha  proper dummy/disabled version that we can maintain than the approach in your patch
16:27:00 <guitarzan> eharney: I think that option doesn't really gain them much
16:27:20 <guitarzan> like DuncanT says, we could add yet another layer of indirection to allow it, but what is the benefit?
16:27:29 <thingee> guitarzan: +!
16:27:32 <thingee> +1*
16:27:33 <avishay> i think there will be more deployers who hate themselves for not enabling it than those happy with the decision
16:27:41 <navneet> DuncanT: do we hve a recommended profiler across openstack projects?
16:27:42 <DuncanT> You can already disable it with a config option
16:27:54 <thingee> I'd also argue that if that if DuncanT wants this other layer, we should hold off on osprofiler :)
16:27:58 <jgriffith> ok... back up, we're confusing this again
16:28:01 <DuncanT> navneet: os-profiler is in several projects already, and spreading
16:28:05 <eharney> yeah i'm getting lost here
16:28:06 <jgriffith> The question is not enable/disable
16:28:06 <hemna> DuncanT, but you are still required to install it, before disabling it in conf.
16:28:11 <jgriffith> it's require the lib for install/run
16:28:29 <DuncanT> thingee: I want os-profiler, but if we /must/ make it optional, do it properly
16:28:46 <navneet> DuncanT: but still it should not be forced to install...may be recommended in docs
16:28:47 <thingee> if you want os-profiler, do it properly
16:28:54 <DuncanT> hemna: And I'm saying requiring it to be installed is fine, same as paramiko and a bunch of other things
16:28:58 <eharney> DuncanT: so properly looks like: all trace points call cinder.utils.profileme, and we handle this logic in there?
16:29:00 <eharney> thingee: +1
16:29:02 <jogo> while I understand the value of something like rally for deployers (they can compare different settings etc.) what does osprofiler buy operators?
16:29:06 <jgriffith> DuncanT: +1
16:29:14 <DuncanT> eharney: Yeah, that sort of thing
16:29:23 <guitarzan> jogo: when stuff gets bad (and it does) you can find out why
16:29:27 <eharney> paramiko does not have to be installed
16:29:28 <eharney> it did
16:29:32 <eharney> and i fixed it for similar reasons
16:29:38 <jogo> guitarzan: for example?
16:29:39 <jgriffith> jogo: the argument is admins having *problems* wanting to dig deeper
16:29:43 <jgriffith> jogo: FWIW
16:29:43 <DuncanT> jogo: Tracing one specific call on a busy live system... it is great
16:29:51 <guitarzan> I think this is an ideological block that we won't all agree on
16:29:55 <jogo> DuncanT: logs do that
16:30:00 <avishay> jogo: when 'cinder list' takes minutes
16:30:09 <guitarzan> jogo: no they don't
16:30:19 <DuncanT> jogo: e.g. a specific customer has 1000 bootable volumes with many items of glance metadata and list takes three minutes, this lets you find out why
16:30:20 <jgriffith> ok, so this is obviously something many different people have opinions on
16:30:27 <jogo> guitarzan: well it depends on what you are looking for
16:30:30 <jgriffith> and may of us may not even be on the same debate :)
16:30:32 <DuncanT> jogo: Logs are a nightmare on a busy system
16:30:40 <hemna> I don't think anyone is questioning the validity of the profiler as a useful tool.   I think we are really questioning 1) if it should be required to run cinder, and if not 2) how to make it optionatl.
16:30:50 <jgriffith> the key question is "requiring libs for cinder services to run"
16:30:52 <jogo> DuncanT: thats why we have request-ids
16:30:52 <eharney> hemna: this is really what i'm trying to focus on
16:30:53 <jgriffith> that's it
16:30:54 <guitarzan> jgriffith: ok, so the basic question is is it ok to "require" people to install this
16:30:55 <navneet> jogo: +1...there are tools out there to scrtinize logs and profile using it
16:31:04 <jgriffith> not the usefulness or use case in prodcution etc
16:31:08 <DuncanT> jogo: Still a nightmare. I was doing it literally last week
16:31:10 <eharney> guitarzan: yes, but require isn't in quotes at present..
16:31:19 <jogo> hemna: I am asking why an *operator* would want it but I think I have somewhat of an answer
16:31:19 <DuncanT> jogo: os-profiler made it very, very easy
16:31:29 <guitarzan> eharney: this is true
16:31:36 <DuncanT> jogo: I *am* an operator of a large public cloud
16:31:45 <guitarzan> jogo: I am another
16:31:55 <avishay> so i see we're not getting anywhere on this... :)
16:32:08 <jgriffith> jogo: so it's a good question, but I don't think it's the question we're trying to answer righ tnow :)
16:32:11 <rushiagr> :)
16:32:11 <guitarzan> jgriffith: so, is it a democracy or a monarchy decision? :D
16:32:16 <jgriffith> IMO that ship has sailed :)
16:32:18 <hemna> jogo, smart operators would find it useful if the performance of cinder starts to suck or whatnot.
16:32:26 <jgriffith> guitarzan: so it's a dictator decision for now :)
16:32:28 <jungleboyj> Are other projects requiring it?
16:32:30 <avishay> hemna: s/if/when/ :)
16:32:31 <guitarzan> jgriffith: works for me
16:32:36 <jogo> jgriffith: yeah just wondering, my question has been answered thanks
16:32:39 <hemna> avishay, :)
16:32:42 <jgriffith> At the end of the day it's no different than a boat load of other things in OpenStack/Cinder
16:32:46 <eharney> jungleboyj: glance, but i think we should make the same patch there
16:32:57 <jgriffith> I say we leave it as is, build the packages
16:33:08 <jgriffith> I'm sympathetic to the problem eharney points out
16:33:12 <jgriffith> BUT
16:33:16 <jungleboyj> So, if requiring it is consistent with other projects and it isn't enabled by default ...
16:33:20 <jgriffith> I think that's a broader question/issue for OpenStack
16:33:25 <hemna> ok so, to make everyone happy, eharney just needs to make this optional with a better mechanism instead of try: blocks around imports ?
16:33:32 <eharney> jungleboyj: it hasn't been around long enough for there to be an understood "consistent"
16:33:37 <navneet> jgriffith: so you will be packaging os-profiler :)
16:33:46 <jgriffith> navneet: no, will you?
16:33:52 <jungleboyj> eharney: Fair enough.
16:33:59 <jgriffith> seriously... why the big scrutiny on this "one" lib?
16:34:00 <eharney> hemna: it sounded to me like we are leaning more toward -2ing the patch still
16:34:03 <navneet> jgriffith: if you start I ll join
16:34:09 <eharney> jgriffith: because it's a service dep and not a driver dep
16:34:16 * DuncanT will be packaging it whether we make it optional or not
16:34:27 <jgriffith> eharney: we have plenty of service deps already
16:34:32 <jgriffith> eharney: this is the model we use
16:34:36 <hemna> eharney, but not because making it optional isn't a good thing, but because of the mechanism for making it optional in your existing patch.
16:34:41 <jgriffith> eharney: My point is if the model sucks, change the model
16:34:44 <avishay> so the next two topics on the agenda seem interesting *subtle hint* :)
16:34:51 <jgriffith> but not with a one off hack out the service
16:34:59 <jgriffith> avishay: haha
16:35:13 <jgriffith> alright, so that's my position on it
16:35:17 <eharney> erm well i'm not really sure where to go from here on this
16:35:18 <jgriffith> I'm sure it's unpopular
16:35:29 <eharney> i.e. whether i should bother improving the patch or not
16:35:35 <jgriffith> eharney: well, my preference is leave it as is and build the rpm's
16:35:49 * DuncanT votes for the same, leave it
16:35:59 <jgriffith> if we want to discuss the model in Kilo and how to make it better for pkg maintainers I think that's great
16:36:12 <jgriffith> but I don't want to mess with a one off right now
16:36:15 <rushiagr> +1
16:36:16 <thingee> jgriffith: +1
16:36:23 <AlkaD_> +1
16:36:23 <eharney> alright
16:36:28 <hemna> ok I'm alright with that.   Lets fix this in K.
16:36:29 <thingee> we have shown we're not getting anyone on irc with it, unfortunately
16:36:31 <jgriffith> and I'm still unclear on the major issue/difficulty that eharney and hemna have with this.
16:36:33 <joa> sounds reasonable :)
16:36:35 <navneet> jgriffith: by Kilo packagers will struggle to have it
16:36:41 <eharney> well in K everyone will have packaged it already
16:36:42 <jgriffith> I mean, I realize building pkgs can suck... but
16:36:44 <avishay> +0.9, but we don't support floats
16:36:48 <avishay> so +1
16:36:49 <eharney> but the architectural points are still valid
16:36:50 <jgriffith> avishay: LOL
16:36:51 <hemna> eharney, yup.
16:36:55 <jgriffith> smart allec
16:37:00 <jgriffith> ok, let's move along
16:37:00 <AlkaD_> lol
16:37:05 <eharney> thanks
16:37:08 <jgriffith> eharney: If it's really an issue we can talk more
16:37:13 <jungleboyj> avishay: :-)
16:37:14 <jgriffith> eharney: as I said, I am sympathetic
16:37:22 <jgriffith> eharney: especially since I don't have to do it :)
16:37:55 <jgriffith> #topic kilo stabilization work
16:37:58 <jgriffith> hemna: ??
16:38:00 * jungleboyj is going to start giving +1.1 's
16:38:10 <hemna> ok, so this list is very large currently on the etherpad
16:38:11 <jgriffith> hey...
16:38:13 <avishay> jungleboyj: watch your quotas... :)
16:38:15 <jgriffith> new rule!
16:38:16 <hemna> https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
16:38:24 <jgriffith> You can't add things 30 minutes into the meeting :)
16:38:28 <kmartin> jungleboyj: good those round up to +2's
16:38:31 <AlkaD_> :0
16:38:33 <hemna> so I'm wondering if we could prioritize this list and see what we think we can actually get done in K.
16:38:36 <AlkaD_> :)
16:38:39 * jungleboyj is laughing  kmartin, yep.
16:38:46 <joa> jgriffith: ahah :D
16:38:58 <jgriffith> hemna: yes
16:39:10 <hemna> some of those items are much larger than others to implement
16:39:11 <jgriffith> hemna: but I'm certainly not ready to do that until we get Juno done
16:39:23 <jgriffith> hemna: or at least an RC out
16:39:24 <avishay> hemna: maybe start by categorizing issues by correctness, robustness, performance/scalability, etc.?
16:39:44 <hemna> sure, anything at this point.  I'm glad we have the list though.
16:40:08 <hemna> we are starting to plan our K work and was wondering what we should be looking at that we might be able to get done.
16:40:20 <hemna> oh and by we, my team here at HP.
16:40:36 <jungleboyj> hemna: Getting the same questions here.
16:40:48 <rushiagr> cinder h/a not there ?
16:40:49 <jungleboyj> by here I mean IBM.  :-)
16:41:02 <hemna> rushiagr, there are items in that list that are required in order to do h/w
16:41:05 <hemna> err h/a
16:41:14 <rushiagr> hemna: okay
16:41:17 <jgriffith> hemna: ok, fair enough
16:41:43 <navneet> any plans on NAMOS in cinder
16:41:45 <avishay> personally i think misusing the DB is the biggest pain point - not doing atomic things atomically, using it for things that it shouldn't be used for, very inefficient calls, etc
16:42:02 <DuncanT> Turning some of these into specs seems like a plan
16:42:15 <DuncanT> I think many are large enough to justify specs
16:42:22 <DuncanT> navneet: NAMOS?
16:42:38 <joa> +1 Duncan, some sound like quite a bit of work
16:42:40 <navneet> DuncanT: configuration management component
16:42:41 <hemna> The state machine seems like a really big want/need
16:42:50 <avishay> DuncanT: +1, and i would add maybe include a sizing estimate in the spec, and people can take on whatever topics they want?
16:43:01 <DuncanT> State machine is the biggest win IMO
16:43:06 <hemna> I'd put that high on the list, whereas the config mgmt seems cool, but a lower priority.
16:43:12 <hemna> DuncanT, +1
16:43:15 <avishay> hemna: +1
16:43:23 <jgriffith> DuncanT: http://www.openstack.org/vote-paris/Presentation/namos-openstack-infrastructure-manager
16:43:30 <jgriffith> re NAMOS ^^
16:43:32 <DuncanT> Config management is a huge feature, and doesn't really fit with the K goals...
16:43:56 <navneet> DuncanT: jgriffithit adressses many probs we already discussed
16:44:13 <hemna> jgriffith, interesting.
16:44:14 <DuncanT> Simple APIs to make an external config manager easier might be reaasonable
16:44:26 <hemna> DuncanT, +1
16:44:31 <jgriffith> anyway... magic beans right now
16:44:35 <thingee> jgriffith, DuncanT: as mentioned at the dev meetup, I can help out after september on state machine.
16:44:49 <thingee> just ci stuff is a priority for me atm
16:44:50 <hemna> DuncanT, but some aspects of doing config mgmt on the fly require the state machine and graceful bouncing of cinder services.
16:45:00 <DuncanT> hemna: +1
16:45:03 <avishay> #1 priority is getting cinder to a point where it's not broken :)
16:45:06 <jgriffith> thingee: yeah, we'll need to work out some POC prior to summit
16:45:12 <jgriffith> avishay: ez now
16:45:12 <thingee> jgriffith: +1
16:45:24 <jgriffith> avishay: don't become one of those "Cinder is broken"
16:46:15 <jgriffith> alright... so
16:46:18 <jgriffith> hemna: great point
16:46:32 <jgriffith> hemna: agreed some planning now rather than later
16:46:39 <jgriffith> I don't know what kind of cycles people have right now
16:46:40 <hemna> so I guess I can see if I can rearrange some of those items in that etherpad
16:46:43 <DuncanT> hemna: I refer you to my 'state machine is the biggest win' comment ;-)
16:46:45 <jgriffith> hemna: +1
16:46:52 <hemna> top down as top priority to lower
16:46:54 <jgriffith> I thnk categories is a great start
16:46:54 <joa> hemna: though some hot-config-changes are sometimes really complex if not impossible
16:46:57 <hemna> I'll take a stab at it.
16:47:05 <hemna> joa, yup.
16:47:08 <jgriffith> also specs
16:47:25 <jgriffith> if somebody is ready to write one they most certainly shouldn't wait
16:47:31 <avishay> jgriffith: ok not broken but not in great shape ;)
16:47:36 <jgriffith> anything else on the topic?
16:47:37 * DuncanT really wants to get two written
16:47:39 <jgriffith> avishay: :(
16:47:45 <hemna> I'm good.
16:47:52 <jgriffith> hemna: cool.. thanks!!
16:47:58 <hemna> np
16:48:11 <jgriffith> #topic Splitting client
16:48:17 <jgriffith> DuncanT: interesting
16:48:20 <DuncanT> So this came up a few times
16:48:27 <DuncanT> Most of our users aren't admins
16:48:37 <avishay> DuncanT: that's good :)
16:48:40 <DuncanT> So why do they get a face full of admin options in the cinder client
16:48:41 <jgriffith> haha
16:48:43 <DuncanT> ?
16:48:44 <joa> too many commandes in one place for different usages ?
16:49:00 <jgriffith> DuncanT: so are you proposing two seperate clients?
16:49:04 <DuncanT> Splitting shell.py in two is fairly easy
16:49:10 <jgriffith> DuncanT: Not sure I like that
16:49:11 <DuncanT> Everything else would be common
16:49:14 <hemna> so migrate more of the admin only stuff into cinder-manage ?
16:49:14 <jgriffith> ahh
16:49:15 <jgriffith> k
16:49:22 <guitarzan> DuncanT: what determines which is admin functionality?
16:49:24 <jgriffith> so then I could just filter basicly
16:49:26 <joa> so it's more a work on the "CLI API", right ?
16:49:33 <avishay> doesn't the policy determine what is admin-only?
16:49:40 <DuncanT> This is purely for the CLI, yeah
16:49:41 <jgriffith> DuncanT: and cheat like "modify policy.json" and still get the "admin" stuff
16:49:44 <jgriffith> ?
16:49:44 <joa> DuncanT: okay
16:50:07 <joa> then I gladly +1 this subject. As a newcomer it's often a nightmare to get all those options/command in your head before you can actually start using it
16:50:08 <jgriffith> guitarzan: yeah, that's kinda where I'm heading
16:50:10 <rushiagr> a decorator will do the job instead of splitting, isn't it?
16:50:16 <jgriffith> rushiagr: +1
16:50:20 <DuncanT> jgriffith: Just because a tenant has perms to do it doesn't make it not admin IMO
16:50:36 <jgriffith> DuncanT: the point is it can't be "all or nothing"
16:50:43 <DuncanT> A decorator might be the solution, I've no strong feelings
16:50:47 <jgriffith> I kinda like the decorator idea
16:50:57 <guitarzan> DuncanT: I was thinking the other way around
16:51:00 <jgriffith> filter out via policy file and present what user is allowed to see/do
16:51:12 <DuncanT> If we can do that, then even better
16:51:17 <jgriffith> guitarzan: what do you mean?
16:51:18 <DuncanT> That would be awesome
16:51:24 <jungleboyj> jgriffith: +2
16:51:29 <jgriffith> DuncanT: we can do *anything* :)
16:51:34 <hemna> jgriffith, +1
16:51:44 <rushiagr> jgriffith: that would be the best solution
16:51:47 <hemna> jgriffith, except make osprofiler optional
16:51:52 <guitarzan> the tenant can't do feature x in my cloud, but can in your cloud, so it's admin in mine, not admin in yours
16:51:53 <hemna> :P
16:51:53 <jgriffith> DuncanT: can we make it scalable, maintainable etc... meh
16:51:54 <jgriffith> :)
16:52:07 <DuncanT> guitarzan: Auto-discovery would be perfect
16:52:22 <joa> jgriffith: the policy file worries me about how to maintain it; (and as you said scaliability etc)
16:52:37 <jgriffith> joa: well that's a different topic though I think
16:52:45 <DuncanT> guitarzan: If not, just call everything that isn't a basic volume op admin even if a tenant can do it - that doesn't make it not admin
16:52:46 <jungleboyj> Yeah, having a policy file is a little worrisome.
16:52:46 <jgriffith> joa: you mean the policy file in general?
16:52:54 <navneet> joa: policy file is a clean way to do it
16:52:57 <jgriffith> joa: not sure I see the problem with that scaling
16:52:58 <joa> jgriffith: I meant in the context of this split
16:53:00 <guitarzan> DuncanT: so the tenant has to use the admin client?
16:53:06 <jgriffith> json is pretty light-weight
16:53:14 <DuncanT> guitarzan: To do admin things, sure
16:53:19 <guitarzan> ok
16:53:22 <jgriffith> guitarzan: I'd propose we don't go that route
16:53:25 <jgriffith> DuncanT: ^^
16:53:29 <guitarzan> I don't like this idea, but I don't care enough to do anything about it
16:53:34 <jgriffith> I thnk that adds a bit of a mess
16:53:38 <DuncanT> guitarzan: I want something less intimidating for none-admins... currently it is rather bad
16:53:51 <jungleboyj> DuncanT: I agree with that.
16:53:52 <jgriffith> it's bad enough I have to do things like novaclient, cinderclient, glanceclient, keystonclient
16:53:59 <guitarzan> DuncanT: yeah, nova had the exact same discussion in atlanta and it didn't go anywhere as far as I can tell
16:53:59 <jgriffith> now if you double that I'm screwed :)
16:54:06 <guitarzan> all about the help text
16:54:12 <DuncanT> Putting everything in one client is a lot more of a mess
16:54:28 <bswartz1> horizon puts everything in one client and it works okay
16:54:30 <jgriffith> DuncanT: maybe, I'd like to investigate the concept of a dynamic load
16:54:36 <DuncanT> Maybe just require a --admin flag to clinder-client for it to mention admin things?
16:54:37 <jgriffith> even if it's just a deocrator/filter to start
16:54:45 <jungleboyj> We need to have a way of using the same client but changing what the users sees depedning on their role.
16:54:54 <jgriffith> DuncanT: hmm... well now that's actually a helpful start IMO
16:55:02 <DuncanT> bswartz1: Horizon hides non-admin things from non-admin people
16:55:02 <avishay> jungleboyj: +1
16:55:03 <jungleboyj> DuncanT: +1 That is helpful.
16:55:03 <jgriffith> jungleboyj: that's what I'm proposing here
16:55:11 <navneet> jgriffith: is decorator to restrict access or it also saves help text to be immited?
16:55:17 <navneet> *ommited
16:55:22 <jgriffith> navneet: both
16:55:29 <joa> jungleboyj: +1;  agreed, it's the simplest for the user.
16:55:36 <jungleboyj> jgriffith: Environment variable that can be set for those of ust that are always wanting admin.
16:55:50 <jgriffith> jungleboyj: ?
16:55:52 <DuncanT> I'm fine with keeping it all in one client if people prefer that... my issue is that simple usecases are hard to see the help for at the moment... anything that fixes that I'm ok with
16:56:02 <jungleboyj> jgriffith: So you don't always have to do --admin
16:56:11 <jgriffith> DuncanT: I think everyody agrees in principal with your goal
16:56:15 <DuncanT> jungleboyj: +1
16:56:20 <jgriffith> jungleboyj: yeah, got ya
16:56:23 <hemna> the one advantage of having it as it is today, is that users can discover what admins can do, so if they need something done, they will ask the admin to do it for them.
16:56:25 <DuncanT> jgriffith: Looks that way. Excellent.
16:56:28 <hemna> people don't read docs.
16:56:35 <jgriffith> jungleboyj: assuming we don't just get the whole shooting match right off the bat
16:56:36 <jungleboyj> hemna: Google
16:56:44 <hemna> jungleboyj, yah
16:56:53 <jgriffith> jungleboyj: the --admin would be a band-aid to just clean up interface IMO
16:56:58 <navneet> jgriffith: change help texts to say its admin only
16:57:05 <jungleboyj> Ok.
16:57:31 <jgriffith> navneet: meh... maybe, but as I said, I'd like to look at filtering first
16:57:32 <hemna> 3 minutes
16:57:34 <jgriffith> and go from there
16:57:36 <jungleboyj> The other thing we could do is change the help text to be more limited.  For admins there is the 'help all' command that shows everything.
16:57:38 * DuncanT might put a PoC patch in (or get somebody on the team to do it, more likely)
16:57:42 <jgriffith> I dont' think anybody disagrees?
16:57:56 <jungleboyj> Sounds like a design session at the summit?
16:57:56 <jgriffith> There's always ways to do interim solutions to clean things up
16:58:00 <navneet> jgriffith: no if we have it in one client and print all available commands...
16:58:16 <jgriffith> navneet: I tink you missed the point
16:58:24 <jgriffith> navneet: one more time... what I'm proposing is:
16:58:33 <jgriffith> single client, filters based on users info
16:58:33 <rushiagr> jgriffith: maybe a discussion on the spec would suffice..?
16:58:51 <navneet> jgriffith: ok..makes sense...
16:58:53 <bswartz1> jgriffith: +1
16:58:56 <jgriffith> if you're creds are admin creds you get it all
16:59:04 <jgriffith> if not, you just get what you have acces to
16:59:07 <jungleboyj> jgriffith: +1
16:59:11 <jgriffith> Ok
16:59:12 <jgriffith> cool
16:59:20 <bswartz1> that's what horizon does, the text client can do it too
16:59:20 <jgriffith> #topic RC
16:59:34 <jgriffith> real quick
16:59:38 <jgriffith> FF has come an gone
16:59:47 <jgriffith> I realize there are things in the pipeline
16:59:49 <jgriffith> that's fine
17:00:02 <jgriffith> but please don't ask for any more FFE's at this point
17:00:06 <xyang1> jgriffith: date for RC1?
17:00:13 <jgriffith> xyang1: when it's ready :)
17:00:23 <bswartz1> https://wiki.openstack.org/wiki/Juno_Release_Schedule
17:00:25 <jgriffith> xyang1: could be a couple weeks
17:00:25 <navneet> we have some bugs in the review pipeline
17:00:31 <bswartz1> Sept 25 according to the schedule
17:00:32 <xyang1> xyang1: ok
17:00:33 <jgriffith> there's lots of bugs
17:00:34 <navneet> chances of getitng them in?
17:00:36 <thingee> time is up
17:00:40 <jgriffith> targetted and in pipeline
17:00:47 <jgriffith> ok.. thanks everybody
17:00:56 <jgriffith> xyang1: we can talk more if you have other questions about that
17:00:57 <AlkaD_> thanks
17:01:00 <jungleboyj> Thanks!
17:01:00 <jgriffith> #endmeeting cinder