16:00:01 <thingee> #startmeeting Cinder
16:00:02 <openstack> Meeting started Wed Apr 29 16:00:01 2015 UTC and is due to finish in 60 minutes.  The chair is thingee. 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:05 <openstack> The meeting name has been set to 'cinder'
16:00:09 <thingee> hi everyone!
16:00:10 <e0ne> hi!
16:00:11 <tbarron> hi
16:00:12 <rhe00_> hi
16:00:12 <smcginnis> howdy
16:00:12 <geguileo> hi!
16:00:15 <cebruns> Hi!
16:00:17 <akerr> o/
16:00:21 <patrickeast> hi
16:00:25 <jungleboyj> o/
16:00:27 <adurbin_> hi
16:00:29 <Swanson> hi
16:00:30 <thingee> announcements!
16:00:31 <rajinir_r> hi
16:00:31 <xyang2> hi
16:00:38 <ameade> o/
16:00:38 <DuncanT> hey
16:00:42 <jungleboyj> Hump Daaay!
16:00:44 <thingee> liberty midcycle meetup date choices are here https://etherpad.openstack.org/p/cinder-liberty-midcycle-meetup
16:00:51 <asselin> o/
16:00:52 <scottda> hi
16:00:57 <kmartin_> o/
16:01:02 <dustins_> o\
16:01:08 <dustins_> err.. o/
16:01:16 <thingee> aug 3-5 or aug 10-12
16:01:30 <thingee> also an idea, extending the meet up for actual hack time
16:01:46 <thingee> or perhaps using the last day for hack time
16:01:53 <thingee> while everyone is in the same room
16:02:05 <thingee> would like feedback from people
16:02:20 <cebruns> Hack time would be awesome!
16:02:32 <smcginnis> +1
16:02:59 <jungleboyj> Not a bad idea.
16:03:06 <DuncanT> I think hack time is definitely worth trying
16:03:18 <thingee> so please provide feedback, and people that are welling to host us, please indicate which date(s) work. if no one can work with these dates, we'll revisit
16:03:24 <thingee> just throwing something out there though to start
16:03:26 <thingee> thanks!
16:03:36 <kmartin_> hack time +1
16:03:50 <winston-d> join late, hack time when?
16:03:52 <adurbin_> +1 on fort collins
16:03:58 <e0ne> +1 for hack time
16:03:59 <winston-d> mid cycle meetup?
16:04:02 <thingee> winston-d: at the midcycle meetup
16:04:06 <winston-d> ok
16:04:15 <thingee> Also reminder spec reviews are happening https://review.openstack.org/#/q/status:open+project:openstack/cinder-specs,n,z
16:04:35 <thingee> would appreciate people helping me with reviews as some of you have been doing already
16:05:24 <thingee> For blueprints that don't require spec, I was wondering, can someone tell me if you're able to mark a blueprint as pending approval?
16:06:04 <thingee> was thinking of announcing to people that they should flag a blueprint as so to get my attention, so I have a queue to look through
16:06:08 <thingee> instead of individual pings
16:06:14 <tbarron> thingee: you mean marking our own, right?
16:06:19 <thingee> tbarron: yes
16:06:31 <tbarron> where a bp within our own driver doesn't need a coresponding spec
16:06:39 <thingee> tbarron: yes
16:06:41 <vilobhmm1> hello everyone gm
16:06:43 <tbarron> thingee: I will try it and let you know later today,
16:06:50 <patrickeast> i just changed one to pending approval, looks like it worked https://blueprints.launchpad.net/cinder/+spec/pure-fc-driver
16:06:56 <thingee> patrickeast: thanks
16:07:15 <thingee> ok, so does that sound ok to everyone? Just mark things as pending approval and I'll watch those?
16:07:20 <tbarron> +1
16:07:24 <thingee> and if I'm being slow, of course let me know
16:07:25 <e0ne> +1,
16:07:29 <thingee> great
16:07:29 <patrickeast> sounds good
16:07:29 <geguileo> +1
16:07:34 <vilobhmm1> +1
16:07:40 <thingee> I'll send an email to let folks know on the list
16:07:44 <xyang2> thingee: do we have to change the approver to your name too?
16:07:50 <thingee> lets get started!
16:07:54 <thingee> xyang2: nah I can do all that
16:08:03 <xyang2> thingee: ok, thanks
16:08:09 <thingee> agenda for today https://wiki.openstack.org/wiki/CinderMeetings#Next_meeting
16:08:22 <thingee> expect a lot of time to be taken on the summit review stuff
16:08:39 <thingee> #topic Cinder Quota delete API behavior
16:08:41 <thingee> geguileo: hi
16:08:45 <geguileo> Hi
16:08:54 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/061000.html
16:09:03 <thingee> #link https://wiki.openstack.org/wiki/APIChangeGuidelines
16:09:15 <geguileo> Ok, so currently quota delete API deletes limits
16:09:37 <geguileo> But also deletes usage and reservations
16:10:00 <geguileo> Acording to API doc it shouldn't: http://developer.openstack.org/api-ref-blockstorage-v2.html#ext-os-quota-sets-cinder
16:10:13 <geguileo> It reads: Deletes quotas for a tenant so the quotas revert to default values.
16:10:55 <geguileo> According API guidelines this API endpoint can be changed without needing a new endpoint
16:11:12 <geguileo> But people don't feel confortable with that
16:11:51 <geguileo> I don't mind either way, but there must be a way for operators to only delete limits (which is usually their intention)
16:12:04 <DuncanT> Deleting usages and reservations looks like a straight bug to me? That can never be the right thing to do, right?
16:12:23 <geguileo> DuncanT: That's what I think
16:12:24 <thingee> DuncanT: Someone who wrote the docs was also confused about this too
16:12:27 <winston-d> In what cases, people want to delete quota for a tenant?
16:12:53 <geguileo> winston-d: You delete the quota limits for a tenant and set it back to the defaults
16:13:25 <winston-d> geguileo: so what's the asnwer to "This is a matter of how the "Quota delete" is understood, as "Delete quotas and leave no quota limits, not even defaults" or just "Delete additional quota limits that override defaults".
16:14:06 <geguileo> winston-d: The answer is that you delete the limits and revert to default as the documentation says
16:14:29 <geguileo> winston-d: It's not about setting it to no restrictions
16:14:29 <winston-d> geguileo: so it's reset-quota-to-default
16:14:41 <geguileo> winston-d: That's what the API docs says
16:14:55 <geguileo> winston-d: "Deletes quotas for a tenant so the quotas revert to default values."
16:15:04 <winston-d> OK. thx
16:15:28 <winston-d> I agree usage and reservations shouldn't be affected by doing that.
16:15:42 <thingee> anyone opposed?
16:16:10 <thingee> geguileo: sounds like no one disagrees
16:16:11 <DuncanT> Just make sure it is clearly release noted, I guess
16:16:16 <vilobhmm1> i agree with DucanT, winston-d
16:16:24 <thingee> DuncanT: +1 upgradeimpact please so we remember to add this
16:16:42 <jungleboyj> dulek: +1
16:16:49 <jungleboyj> DuncanT: +1
16:16:57 <thingee> #agreed usage and reservations should not be affected
16:17:04 <thingee> geguileo: thanks
16:17:04 <geguileo> Ok, I will modify the commit message of current patch: https://review.openstack.org/#/c/162722/
16:17:06 <jungleboyj> Sorry dulek ... unpredictable tab completion.
16:17:08 <geguileo> Thanks guys
16:17:31 <thingee> #topic Liberty Summit Sessions
16:17:32 <dulek> jungleboyj: I was surprised. ;)
16:17:33 <thingee> #link https://etherpad.openstack.org/p/cinder-liberty-proposed-sessions
16:17:40 <thingee> alright here we go
16:18:15 <jungleboyj> :-)
16:18:19 <thingee> lets start with working sessions
16:18:29 <thingee> because I have a feeling we'll be moving some out to fish bowl maybe
16:19:03 <thingee> Very small discussion if we think these topics will be worth technical discussion
16:19:09 <thingee> remember working sessions is a smaller room
16:19:21 <thingee> not meant for user interaction
16:19:30 <thingee> these are things we already agree have a clear use case.
16:19:43 <thingee> if we're unsure of use case, might be best to propose to fish bowl to get feedback
16:19:55 <thingee> ok first up, Task resumptions
16:19:59 <thingee> dulek: hi
16:20:09 <thingee> #link https://review.openstack.org/#/c/147879/
16:20:26 <dulek> Hi guys!
16:20:32 <thingee> #topic Task Resumptions
16:20:51 <dulek> I've updated the spec with what I think would work.
16:21:07 <thingee> so at this point, this is something I think we all want in Cinder. the question is how the approach will be
16:21:16 <tbarron> +1
16:21:22 <dulek> So basically I want to discuss if this is sane at gather feedback
16:21:28 <dulek> Maybe redesign some things.
16:21:28 <thingee> does this currently have a tie with decisions in another topic dulek ?
16:21:29 <e0ne> +1
16:21:31 <thingee> like taskflow?
16:21:40 <thingee> would like to make sure I schedule things in the right order
16:21:50 <e0ne> we could start with PoC based on taskflow before summit
16:21:58 <dulek> Yeah, I'm assuming TaskFlow would stay.
16:22:23 <thingee> ok where's the discussion on taskflow?
16:22:24 <e0ne> #link https://etherpad.openstack.org/p/cinder-taskflow
16:22:40 <thingee> can someone move that to the topic of working sessions
16:22:55 <thingee> dulek: can you make yours as dependent on that discussion? just so I schedule things in the right order
16:23:08 <e0ne> thingee: do you want a separate session?
16:23:11 <dulek> thingee: Okay, I'll do that.
16:23:14 <vilobhmm1> thingee : i have one https://etherpad.openstack.org/p/resiliency-with-without-statemanagement
16:23:16 <thingee> e0ne: I thought there was going to be one
16:23:46 <thingee> Any others that are dependent on taskflow should state so...just so I schedule things in the right order
16:23:48 <vilobhmm1> myself and duncanT will be covering it under "Active / Active cinder-volume: Towards better resiliency, the way forward "
16:23:51 <e0ne> thingee: agree, that's why i didn't add topic about TF
16:24:24 <vilobhmm1> thingee : have updated the liberty session link with it already
16:24:36 <tbarron> I think it's a mistake to just move ahead working on designs that assume taskflow w/o having the meta conversation first.
16:24:45 <DuncanT> tbarron: ++
16:24:51 <vilobhmm1> +2
16:24:56 <thingee> DuncanT, vilobhmm1 I think there is some work anthony lee is doing towards this effort
16:25:03 <thingee> of removing locks
16:25:15 <thingee> can we make sure his work is part of this?
16:25:23 <hemna> https://review.openstack.org/#/c/149894/
16:25:25 <vilobhmm1> thingee : but first we need to clearly outline all the problem
16:25:25 <hemna> those locks
16:25:26 <hemna> :P
16:25:32 <DuncanT> thingee: There are several people working on it. Part of the problem is that there are several related problems
16:25:34 <vilobhmm1> sure i am ok with tha
16:25:38 <thingee> #topic active/active cinder-volume
16:25:46 <hemna> removing those locks, requires fixes in Nova, and nova tempest tests and gate tests.
16:25:47 <hemna> FYI
16:25:56 <winston-d> tbarron: +1
16:26:20 <DuncanT> There are two sets of locks, the ones in the manager and the ones in individual drivers... both doing different jobs
16:26:23 <vilobhmm1> yes..fixing locking issues in manager, drivers etc…also
16:26:27 <vilobhmm1> true
16:26:42 <winston-d> hemna: why a cinder internal implementation has external dependency on Nova?
16:26:57 <hemna> https://review.openstack.org/#/c/149894/
16:27:00 <hemna> that's the spec
16:27:12 <hemna> winston-d, because the changes in Cinder causes different API behavior
16:27:13 <dulek> winston-d: Because Nova is checking the state and assumes that it won't change before making an action.
16:27:17 <dulek> winston-d: That's wrong.
16:27:38 <hemna> that Nova doesn't account for.  Nova is currently not catching any possible exceptions that might come back from calling Cinder.
16:27:41 <hemna> nova blows up.
16:27:45 <hemna> bad mmmmkay
16:27:53 <jungleboyj> :-)
16:28:15 <vilobhmm1> dulek : i guess we have covered most of the things here https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues
16:28:32 <thingee> ok seems fine to keep IMO
16:28:38 <dulek> #link https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues
16:28:48 <thingee> keep in mind we have eight slots here. ... 17 are on this list if I counted right
16:29:11 <thingee> so lets be picky and merge things when necessary :)
16:29:15 <dulek> thingee: Shall we move some to be discussed at friday in smaller subteams?
16:29:27 <thingee> dulek: yeah, but I think this is fine
16:29:42 <thingee> #topic API and contracts between nova and cinder
16:30:05 <thingee> DuncanT scottda hemna hi
16:30:11 <hemna> hey
16:30:20 <DuncanT> Hey
16:30:23 <scottda> hey
16:30:25 <DuncanT> We discussed this earlies
16:30:29 <DuncanT> earlier
16:30:29 <thingee> so no details on this yet, but I agree we have a falling out a bit
16:30:34 <hemna> So we started taking a look at the contract between Nova and Cinder interactions.
16:30:45 <DuncanT> There are two strands: simple fixes to what is there
16:30:49 <hemna> and DuncanT and I are going to try and throw together a WIP spec to look at this
16:30:55 <DuncanT> And a re-do to do it properly
16:31:02 <hemna> as a parallel effort to what exists today.
16:31:06 <DuncanT> There should be a spec before the summit
16:31:28 <scottda> And we are told that Nova is very interested in this as well.
16:31:38 <scottda> i.e. supportive
16:31:48 <winston-d> big +1
16:31:56 <thingee> so I would say move this to sprints. If you are actually going to get nova folks to show up, might be worth while.
16:32:22 <winston-d> vol attach/detach failure has been our no.1 issues of Cinder, which unfortunately all happened in Nova
16:32:35 <scottda> winston-d +1
16:32:54 <e0ne> winston-d: +1
16:33:03 <hemna> there are a lot of 'bad' things that nova is doing with cinder currently, and will try and encapsulate those fixes along with attach/detach APIs in the spec.
16:33:09 <tbarron> winston-d: +1
16:33:10 <ameade> +1
16:33:16 <hemna> live migration being another PITA
16:33:23 <ameade> hemna: +1
16:33:46 <tbarron> ameade: you have the right to say that :-)
16:33:49 <thingee> DuncanT, scottda, hemna can we do some communication to let nova folks know about this session?
16:33:51 <e0ne> hemna: we've got one more session proposal  with live migration
16:33:52 <xyang2> hemna: we have a related patch in nova and would like your feedback.  I'll send you a link of it.
16:34:00 <jungleboyj> winston-d: +1
16:34:00 <thingee> are there going to be conflicts to have interested parties attending?
16:34:04 <hemna> xyang2, ok thanks
16:34:26 <hemna> thingee, my thoughts were, lets figure out what our API should be, and then pull in the Nova folks
16:34:35 <hemna> so we don't get bogged down in theoreticals
16:34:59 <hemna> but also just touch base with them and let them know this is an issue we see value in addressing.
16:35:08 <thingee> seems like we can keep this in the sprints then if we're just talking amongst ourselves then?
16:35:17 <hemna> sure
16:35:24 <jungleboyj> thingee: +1
16:35:27 <thingee> someone mind moving that to sprints?
16:35:49 <scottda> will do
16:35:59 <thingee> #topic cinder agent /ironic integration
16:36:18 <hemna> :)
16:36:35 <thingee> so we don't have a cinder agent yet. not sure it's worth having at the working sessions yet.
16:36:44 <thingee> but the ironic interaction
16:36:54 <e0ne> ironic team is interesting in it too
16:36:58 <hemna> sorrison, e0ne and I were looking at this one
16:37:01 <hemna> gah
16:37:02 <hemna> so
16:37:13 <hemna> it's basically a REST API in front of os-brick
16:37:22 <hemna> and made into a standalone service.
16:37:58 <e0ne> i hope, we could get some working agent poc before summit
16:38:11 <hemna> to manage fetching the initiator information, as well as volume discovery and detachment.
16:38:38 <hemna> e0ne, if we ignore the authentication stuff for now, we could get a POC REST api working pretty quickly in front of os-brick
16:39:00 <e0ne> hemna: i want to finish auth staff this weekend:)
16:39:09 <hemna> basically 3 APIs, get_connector, discover_volume, detach_volume
16:39:21 <hemna> e0ne, we should talk about that offline.
16:39:26 <e0ne> hemna: agree
16:39:27 <thingee> hemna: what do we plan to be discussed if this was a working session?
16:40:00 <hemna> the auth piece is a bit of a mystery to me and has security related issues
16:40:01 <e0ne> thingee: we need to notify ironic team when we'll get it
16:40:12 <hemna> thingee, we can chat offline if you like.
16:40:49 <thingee> ok, just trying to decide if this is beneficial at this point to have ironic folks attend or if this something we can do in the sprints.
16:40:59 <winston-d> hemna: make sure new REST API service get the active-active HA piece right. ;)
16:41:05 <hemna> winston-d, :P
16:41:14 <thingee> right now it seems like it would be great to hack on this in the sprints? instead of rushing for POC at the summit?
16:41:15 <e0ne> winston-d: ok:)
16:41:21 <hemna> thingee, it might be worth pulling in the ironic folks
16:41:33 <thingee> they might also be at the sprints.
16:41:35 <hemna> thingee, in the past, I know that deva was against having agents running on the BM
16:41:42 <hemna> not sure if that's changed though.
16:41:57 <thingee> devananda: you plan to be part of this if no conflicts?
16:42:03 <hemna> but the only way to do volume attaches/detaches is with an agent.
16:42:08 <thingee> if it's a working sessions at the summit?
16:42:27 <thingee> ok running out of time on this one, so maybe...
16:42:33 <hemna> ok
16:42:42 <thingee> #topic online backup using snapshot
16:42:45 <thingee> DuncanT, xyang2 hi
16:42:56 <xyang2> hi, so we discussed about this at the meetup
16:43:12 <xyang2> I just want to have more detailed discussion on the API design
16:43:16 <xyang2> and nail it down
16:43:50 <thingee> xyang2: +1 for sprints shouldn't be too controversial?
16:44:13 <xyang2> that is fine.  I just want to discuss about it
16:44:19 <xyang2> and make sure we are in sync
16:44:38 <DuncanT> Needs input from vendor experts, ideally, though we can do a safe fallback and just create a hidden volume from snap if necessary
16:44:38 <xyang2> by the way, what are doing at sprint that is not in a working session?
16:44:42 <thingee> I think for sprints we'll have discussions at the first half, and the second half of the day will be actually working.
16:45:35 <xyang2> DuncanT: I thought we want to avoid creating a volume?  Seems slower
16:45:35 <thingee> xyang2: working sessions is technical discussion on implementation details, but involves other parties
16:45:44 <thingee> not sure just us talking to each other
16:46:06 <thingee> so vendors will still be encouraged to show up
16:46:18 <DuncanT> xyang2: Where it is possible to do data transfer from the snap, we optimise, but that is a new requirement
16:46:36 <thingee> #agreed move to sprints
16:46:41 <DuncanT> xyang2: We need a fallback path
16:46:45 <xyang2> DuncanT: ok
16:46:54 <thingee> #topic automatically sync up service catalog
16:46:56 <thingee> xyang2: hi
16:46:58 <xyang2> DuncanT: yes, driver needs to implement attach snapshot
16:47:23 <xyang2> thingee: this is somewhat related to your topic on capabilities.
16:47:33 <DuncanT> I have no idea what this is referring to
16:47:39 <dulek> DuncanT: +1
16:47:47 <xyang2> thingee: so we are doing a POC trying to automatically read data from array and build service catalog
16:48:00 <thingee> service catalog to me is keystone
16:48:09 <thingee> am I right what you're talking about here?
16:48:11 <xyang2> service catalog here refers to volume types and extra specs
16:48:14 <e0ne> xyang2: do you have a spec for it?
16:48:19 <hemna> xyang2, what do you mean by service catalog ?
16:48:22 <xyang2> not yet
16:48:23 <hemna> that's completely unclear to me.
16:48:34 <xyang2> I can definitely add more info to it.
16:48:35 <thingee> xyang2: need more information.
16:48:40 <DuncanT> Can we rename it, right now, please? Reusing the name 'service catalogue' is just inviting confusion
16:48:40 <hemna> ok coolio
16:48:53 <xyang2> service catalog means volume types and extra specs.  Sure I can rename
16:48:55 <hemna> I was thinking cinder-manage service list
16:48:55 <hemna> heh
16:48:56 <thingee> xyang2: but if we can merge it into the capabilities stuff, I'm fine with that...just have no idea what this is
16:49:02 <tbarron> xyang2: I think we call that service catalog too :-)
16:49:13 <xyang2> tbarron: that is what I think:)
16:49:14 <thingee> no service catalog please :(
16:49:16 <tbarron> all the more reason to rename
16:49:18 <hemna> thingee, +1
16:49:26 <xyang2> thingee: ok, I can rename it.
16:49:29 <thingee> #agreed may merge into capabilities fish bowl talk
16:49:43 <thingee> #topic abc meta driver
16:49:46 <xyang2> thingee: let me create an etherpad for it
16:49:47 <thingee> mkoderer: hi
16:49:57 <thingee> I think this will be fine for sprints
16:50:07 <thingee> sprints should have active maintainers
16:50:23 <xyang2> tbarron: I think I saw "service catalog" on netapp patches.  so thought this is commonly accepted terms:)
16:50:40 <winston-d> thingee: +1 for sprint
16:50:54 <thingee> #agreed ABC meta driver to be in sprints
16:50:57 <tbarron> xyang2: :)
16:51:06 <thingee> #topic the state of live instance migration with attached volumes
16:51:26 <thingee> so I thought this would be great for fishbowl. I understand we'll be technical, but I think there is a bit of misconception on this to users?
16:51:35 <thingee> people say it works, doesn't work, use this patch
16:51:42 <ameade> yeah exactly
16:51:42 <hemna> yah it's a mess
16:51:47 <thingee> should be a full room
16:51:52 <tbarron> ameade: +1
16:51:55 <vilobhmm1> +1
16:51:57 <vilobhmm1> agree
16:51:59 <winston-d> +1
16:52:00 <thingee> ameade: I would also like jgriffith to help with this...
16:52:00 <hemna> and there are some really bad assumptions that the nova code is making wrt connector information coming back from cinder drivers.
16:52:01 <kmartin_> thingee, +1
16:52:02 <dulek> thingee: +1
16:52:11 <thingee> #agreed move to fishbowl
16:52:15 <ameade> sounds good
16:52:21 <xyang2> hemna: do you have a bug number for the problem you see?  we tested a few days ago and it worked
16:52:27 * thingee hopes people are updating the etherpad as he quickly makes decisions
16:52:31 <hemna> xyang2, yah I have a few
16:52:35 <thingee> #topic shadow tables implementation
16:52:41 <dulek> thingee: We're trying to catch up. ;)
16:52:45 <thingee> e0ne: hi
16:52:53 <e0ne> we can move it to Friday:)
16:52:54 <thingee> initially going to say sprints for this
16:52:57 <thingee> ha
16:53:01 <thingee> #agreed move to sprints
16:53:10 <thingee> #topic REST API: volume detailed view
16:53:14 <thingee> sprints?
16:53:54 <e0ne> may be. need to discuss how can/should we change our REST API
16:54:25 <winston-d> e0ne: i thought we don't change API, just the implementation of it, no?
16:54:29 <DuncanT> We're putting a lot of things in sprints now... that is going to cause some reduction in focus... how many sprint sessions do we think we have?
16:54:55 <e0ne> winston-d: i mean extend api to return more fields
16:55:05 <ameade> couldnt the client just make multiple requests?
16:55:10 <thingee> DuncanT: it'll be fine. there should be initial discussion, but people are going to break up into their stuff in the second half of the day
16:55:17 <DuncanT> Returning more fields we can just do....
16:55:32 <dulek> DuncanT: +1
16:55:35 <e0ne> DuncanT: not everybody agrees with it:(
16:55:46 <DuncanT> thingee: Some of these are not going to be all that quick to discuss, I think
16:55:48 <ameade> +1
16:55:49 <thingee> e0ne: I agree with it. Is that good enough? :)
16:56:01 <winston-d> DuncanT: +1
16:56:05 <DuncanT> e0ne: We've done it before, it's documented API policy that we do it
16:56:06 <e0ne> thingee: ok. i'll wait +2 on spec;)
16:56:13 <thingee> we've always been fine with adding more fields
16:56:15 <DuncanT> e0ne: Where is the spec?
16:56:29 <thingee> just changing/removing fields is a no no
16:56:36 <e0ne> #link https://review.openstack.org/#/c/156292/
16:56:46 <thingee> e0ne: like I said sprint should be fine, but sounds like we can resolve this in the spec.
16:56:55 <vilobhmm1> +1
16:56:57 <thingee> #action thingee to decide after reviewing spec
16:56:57 <vilobhmm1> thingee
16:56:59 <ameade> yeah i may have some concerns, i need to readup some
16:57:11 <e0ne> thingee: fair enough. thanks!
16:57:31 <DuncanT> e0ne: Ah, you are proposing removing stuff from the default... that is harder
16:57:40 <thingee> #topic nested quota driver
16:57:43 <thingee> vilobhmm1: hi
16:57:47 <vilobhmm1> hi thingee
16:57:58 <DuncanT> thingee: that REST API stuff does need discussion IMO
16:57:58 <vilobhmm1> have uploaded blueprint , spec
16:58:02 <e0ne> DuncanT: maybe my fault. i mean _extend_ current defults
16:58:03 <thingee> is there a cross project initiative on this? could it be discussed there?
16:58:15 <vilobhmm1> it has detailed use cases mentioned
16:58:29 <DuncanT> e0ne: Shall we talk after the meeting?
16:58:37 <e0ne> DuncanT: sure
16:58:45 <thingee> 2 min warning
16:58:47 <vilobhmm1> no cross project initiative that i know of…keystone has done work on heirarchical stuff and that was accepted in kilo
16:59:00 <vilobhmm1> nova started work on same
16:59:11 <vilobhmm1> i think we also need to gear up in same direction
16:59:19 <vilobhmm1> as the community is moving for that support
16:59:24 <thingee> what do we need to discuss exactly?
16:59:33 <vilobhmm1> the implementation
16:59:44 <vilobhmm1> the effects that it will have, the use-cases
16:59:57 <thingee> fish bowl maybe?
17:00:01 <thingee> maybe
17:00:09 <thingee> out of time
17:00:15 <thingee> continue on #openstack-cinder
17:00:17 <thingee> #endmeeting