21:01:33 <nikhil> #startmeeting quotas-wg
21:01:33 <openstack> Meeting started Mon Feb 29 21:01:33 2016 UTC and is due to finish in 60 minutes.  The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:37 <openstack> The meeting name has been set to 'quotas_wg'
21:01:42 <ninag> hi
21:01:46 <mc_nair> hey there
21:01:49 <nikhil> #topic roll call
21:01:59 <vilobhmm11> vilobhmm
21:02:02 <vilobhmm11> o/
21:02:07 <nikhil> I see vilobhmm11, ninag and mc_nair already here
21:02:20 <nikhil> Let's wait a couple mins for folks to show up
21:02:58 <vilobhmm11> sure
21:03:06 <nikhil> Let me highlight reminder
21:03:08 <nikhil> Courtesy meeting reminder: nikhil, vilobhmm, DuncanT, mc_nair, <add your nick before>
21:04:04 <vilobhmm11> lets start
21:04:17 <nikhil> #topic agenda
21:04:20 <DuncanT> Hi. Posting from my mobile, so a touch lagged, sorry
21:04:25 <nikhil> #link https://etherpad.openstack.org/p/quotas-wg-meeting-agenda
21:04:29 <nikhil> HI DuncanT
21:04:35 <nikhil> thanks for adding items to the agenda
21:04:42 <nikhil> great to see input already!
21:04:42 <vilobhmm11> +1
21:05:00 <nikhil> This is our first meeting
21:05:26 <nikhil> so the purpose is for everyone to get introduced, express level ofinterest and define scope and objectives
21:05:49 <nikhil> We also wanted to get some early eyes on the spec and establish momentum in the freeze period
21:06:11 <nikhil> so that we can have some clear, concise and productive conversations at the summit
21:06:48 <nikhil> Also, one aim is to gather input at this close-nit gathering and then share insights to the wider audience from time to time at the regular cross project meetings
21:07:14 <nikhil> So, let's start with a very brief introductions, interests etc.
21:07:21 <nikhil> #topic Introductions, interests, objectives, etc.
21:07:52 <nikhil> I can go first in people prefer..
21:08:17 <mc_nair> sure :)
21:08:39 <nikhil> I am Nikhil Komawar, primarily focusing on Glance and Searchlight :)
21:09:10 <nikhil> I am interested in this work to get cross project input to glance for the quotas work in the coming up cycle and help prioritize it.
21:09:35 <mc_nair> hey - I'm Ryan McNair - work on Cinder and have been doing a lot of work with Nested Quotas in Cinder for the past month or so
21:09:44 <DuncanT> I'm DuncanT, cinder core, and my main interest is in seeing this attempt not repeat the mistakes that the cinder nested quota code made, which can be subsided quite easily in one line :-) It should be noted in terrible at actually finding time to write code, but I'm pretty good on reviews
21:09:58 <DuncanT> Duncan Thomas, HPE currently
21:10:12 <nikhil> ++
21:10:20 <nikhil> vilobhmm11: you're next
21:10:31 <nikhil> vilobhmm11: I am aware that you
21:10:37 <nikhil> you've a conflicting mtg
21:10:44 <nikhil> so if you want me to move please send a ack
21:10:50 * smcginnis is lurking
21:10:59 <vilobhmm11> vilobhmm I am Magnum core. I have worked in the areas of Quotas in Nova/Cinder/Magnum. Problems with quotas in normal use-case and at scale.
21:10:59 <nikhil> :)
21:11:03 <vilobhmm11> First to introduce and implement Nested Quota in Cinder
21:11:12 <vilobhmm11> Working on Quota Flavor Classes, Quota by Flavor, Quota by Availability Zone, Quota by X
21:11:29 <vilobhmm11> so have worked/focussed more on quota in general :)
21:11:44 <vilobhmm11> the aim is to make a common entity
21:11:53 <vilobhmm11> which will be useful for all the projects
21:12:10 <vilobhmm11> and new upcoming projects who plan to use quota does nto have to re-invent the wheel
21:12:17 <vilobhmm11> and spend additional cycles
21:12:50 <ninag> ’m Nina Goradia…interested in getting hierarchical quota support in Glance..would like it to be consistent across projects, but am open to whether or not it needs to be a common code base
21:13:47 <nikhil> vilobhmm11: thanks, glad to get your insights!
21:13:53 <nikhil> ninag: and that sounds like a good point to discuss early on!
21:14:35 <nikhil> I guess those are all  for today.
21:14:47 <nikhil> Thanks everyone, glad to know the interest groups.
21:14:56 <vilobhmm11> nikhil : Few points we should dicsuss early on : #1. whether common code base (Y/N) #2. If common code base then should it be a library or a service
21:15:23 <vilobhmm11> just to add to ninag
21:15:26 <nikhil> vilobhmm11: sounds good, should we do that for open discussion today and carry it on next week?
21:15:56 <vilobhmm11> nikhil : open discussion  sounds good to me;
21:16:00 <nikhil> cool
21:16:08 <nikhil> Moving on
21:16:14 <nikhil> #topic Spec (vilobhmm)
21:16:22 <nikhil> #link https://review.openstack.org/#/c/284454/
21:16:32 <nikhil> vilobhmm11: mind giving us a tl;dr; version?
21:16:43 <vilobhmm11> sure
21:16:46 <nikhil> (for record keeping here in the logs)
21:16:58 <vilobhmm11> so would request everyone to have a look and give there feedback
21:17:44 <vilobhmm11> right now i don't want to get into library vs service debate as that is the main reason why this *idea of common quota thingee* didn't made in the past
21:17:50 <vilobhmm11> so calling it an entity
21:17:57 <vilobhmm11> we can discuss what it should be
21:18:00 <vilobhmm11> library/service
21:18:51 <vilobhmm11> so goal here is to have a common *entity* which #1. minimizes or zeros down the code duplication #.2 New project and use it and enable quota #3. New features like nested quota, quota by x can be added on demand
21:19:16 <vilobhmm11> #2.New project can use it and enable quota
21:19:48 <vilobhmm11> that is the *WHY* part
21:20:09 <vilobhmm11> now about *HOW* to do it have included details in the "Proposed change" section please have look
21:20:24 <vilobhmm11> all feedbacks are welcome :)
21:20:47 <nikhil> ++
21:21:10 <nikhil> I guess that sort of pushes the discussion around the scope of the cross-prj initiative
21:21:19 <mc_nair> cool, will take a look at the spec right after the meeting
21:21:20 <vilobhmm11> yup
21:21:35 <nikhil> To me it seems like we really need to understand the use cases for proposing a new project
21:21:38 <vilobhmm11> hence renamed the spec as well to "Delimiter - Cross Project Quota Enforcement and Management"
21:21:58 <vilobhmm11> nikhil : sure
21:22:14 <nikhil> It would be a overhead for maintaining a new service for quotas if projects can't implement it internally
21:22:34 <nikhil> And that's another part of the scope discussion comes into play
21:22:51 <nikhil> I would like to know
21:23:10 <vilobhmm11> nikhil : Regarding use-case for a new project/library/entiry - few details are covered here https://review.openstack.org/#/c/284454/4/specs/quota-library.rst as part of "Problem Description"
21:23:53 <nikhil> vilobhmm11: ++
21:24:08 <vilobhmm11> nikhil : three of the most common problems that were seen as part of ops meetup and previous dev meetup are jotted down here https://review.openstack.org/#/c/284454/4/specs/quota-library.rst
21:24:12 <nikhil> I agree on the technical implications and the optimizations aspects of things
21:24:48 <nikhil> I would agree to those
21:25:13 <nikhil> and have had the pleasure of experiencing the #3 of that many a times first hand ;)
21:25:32 <nikhil> my use case concerns were around:
21:25:34 <nikhil> 1. Are there custom glitches in projects around quotas? (one feature/resource dependent on another in subtle way)
21:25:48 <DuncanT> I can't follow all those links right now, sorry, I'll have to catch up later
21:26:29 <nikhil> 2. Do projects need to have DB migrations that would affect quotas work and that can't be handled outside of the project scope? (May be upgrades, or quota lib adding a dependency to oslo.vo?)
21:26:50 <nikhil> DuncanT: np
21:27:04 <vilobhmm11> these are good points and i think we should cover it as part of spec
21:27:09 <vilobhmm11> nikhil : ^^
21:27:19 <mc_nair> nikhil: for 1) are you referring to quotas that are related/dependant?
21:27:20 <vilobhmm11> i can update the spec with more details
21:27:41 <nikhil> 3. If done as a separate project, how do we take care of cross-resource transactions within the project?
21:28:04 <nikhil> mc_nair: yes, quotas that are dependent
21:29:06 <nikhil> vilobhmm11: the #3 is my perspective of images and image members in glance.
21:29:27 <nikhil> members are not independent of images but
21:29:45 <nikhil> image <-> members have a many to many relationship
21:30:19 <nikhil> oops, I realized that we're running over.
21:30:34 <nikhil> For some reason, forgot this was a 30 mins meeting. sorry about that.
21:30:43 <nikhil> Do folks mind carrying this for another 5 mins?
21:30:56 <nikhil> I do not think there's another meeting in this room.
21:30:59 <mc_nair> I don't mind
21:31:04 <nikhil> ok great.
21:31:23 <nikhil> anyone else, have objections?
21:31:49 <ninag> nope, I can continue
21:32:06 <DuncanT> I'm fine continuing
21:32:12 <nikhil> #info meeting to be carried on till 2135 UTC
21:32:39 <mc_nair> quickly running out of time on that too :)
21:32:40 <nikhil> So, to better define the scope , I think we need a wider use case feedback.
21:33:01 <nikhil> And thanks vilobhmm11 for willing to add some initial thoughts on those in the spec.
21:33:15 <nikhil> It would be good to get them on the review or during CP meetings.
21:33:27 <vilobhmm11> nikhil : sure…but this problems is only for existing projects who have quotas right now..and we need to think on migration plan before the switch happens
21:33:36 <DuncanT> Just to get my 5 cent worth in, my main point was going to be that you need to specify behaviours, including corner cases, in extreme detail, from the beginning... Figuring then out as you go doesn't work out, and writing the tests first is probably a good way to proceed
21:34:19 <nikhil> vilobhmm11:  and DuncanT: both are great points indeed!
21:34:30 <nikhil> but they conflict  a bit ;)
21:34:49 <nikhil> I would like us to think about the migration and if that's a possibility..
21:34:56 <nikhil> but the first point to answer is:
21:35:04 <nikhil> 1. separate repo or not
21:35:11 <nikhil> 2. if yes, lib or project
21:35:31 <vilobhmm11> nikhil : those are the starting points imho
21:35:34 <nikhil> and that would be essential to get from other projects too I think
21:35:51 <nikhil> and we're out of time again :)
21:36:04 <DuncanT> Separate repo is the only way that I can see this making progress without falling into the mess of fixing a specific project's bugs
21:36:22 <DuncanT> Lib or project I don't care
21:36:22 <mc_nair> +1
21:36:35 <nikhil> ok, that sounds good.
21:36:43 <vilobhmm11> if we have a concensus on 1. separate repo or not 2. if yes, lib or project we have a clear path and should then think of migration, testing
21:37:07 <nikhil> what do ppl think for adding a voting section on the spec on this topic?
21:37:17 <vilobhmm11> nikhil : ^^
21:37:20 <nikhil> this == separate repo or not
21:37:23 <DuncanT> What is the practical difference between a lib and a project?
21:37:42 <vilobhmm11> DuncanT : library vs service (project)
21:37:45 <nikhil> DuncanT: project would mean a API backed by DB
21:37:47 <vilobhmm11> is what nikhil meant
21:38:16 <DuncanT> Got you. Thanks
21:38:19 <nikhil> more like: Quotas as a Service (QaaS)
21:38:57 <DuncanT> The downsides of going through an API are a) failure modes and b) latency
21:39:08 <ninag> I think a separate repo makes sense..and if the behavior is fleshed out and documented..then it will help decide whether it meets all needs from projetcs
21:39:19 <DuncanT> The upsides are debugability and consistency
21:39:34 <ninag> or whether we have the cross-resource dependencies..and will help towards the library or project decision
21:40:12 <DuncanT> I think the consumer entry points are pretty much the same whether we go project or lib (reserve, commit, unreserved, list, edit, etc)
21:40:20 <nikhil> DuncanT: yeah, I think another downside is "concurrency issue" for intra-prj resources
21:41:00 <nikhil> DuncanT: yes, agreed on the entry points.
21:41:31 <nikhil> ok, I think we'd call off on the meeting today. We can definitely continue the discussion on #openstack-dev if we like.
21:42:28 <DuncanT> I think we've got plenty to think about anyway
21:42:34 <nikhil> sorry for running over and we will try to be more precise from next week onwards in case people have conflicts and prior commitments.
21:42:46 <mc_nair> sounds good
21:42:49 <nikhil> DuncanT: agreed
21:42:52 <nikhil> Thanks all for joining.
21:43:07 <nikhil> #endmeeting