Thanks everyone for being there at the Design Summit talk on Cross project Quotas.
Points from the discussion are captured in this etherpad[1] for reference. -Vilobh [1] https://etherpad.openstack.org/p/newton-quota-library On Tue, Apr 26, 2016 at 9:33 AM, Jay Pipes <jaypi...@gmail.com> wrote: > On 04/25/2016 02:05 PM, Joshua Harlow wrote: > >> Is the generation stuff going to be exposed outside of the AP? >> > > No, wasn't planning on it. > > I'm sort of hoping not(?), because a service (if one everyone wanted to >> create it) for say zookeeper (or etcd or consul...) could use its >> built-in generation equivalent (every znode has a version that u can use >> to do equivalent things). >> >> Thus it's like the gist I posted earlier @ >> >> https://gist.github.com/harlowja/e7175c2d76e020a82ae94467a1441d85 >> >> So might be nice to not expose such a thing outside of the db-layer. >> >> Amrith Kumar wrote: >> >>> On Sat, 2016-04-23 at 21:41 +0000, Amrith Kumar wrote: >>> >>>> Ok to beer and high bandwidth. FYI Jay the distributed high perf db we >>>> did a couple of years ago is now open source. Just saying. Mysql plug >>>> compatible .... >>>> >>> >>> -amrith >>>> >>>> >>>> -- >>>> Amrith Kumar >>>> amr...@tesora.com >>>> >>>> >>>> -------- Original message -------- >>>> From: Jay Pipes<jaypi...@gmail.com> >>>> Date: 04/23/2016 4:10 PM (GMT-05:00) >>>> To: Amrith Kumar<amr...@tesora.com>, >>>> openstack-dev@lists.openstack.org >>>> Cc: vilob...@yahoo-inc.com, nik.koma...@gmail.com, Ed Leafe >>>> <e...@leafe.com> >>>> Subject: Re: [openstack-dev] More on the topic of DELIMITER, the Quota >>>> Management Library proposal >>>> >>>> >>>> Looking forward to arriving in Austin so that I can buy you a beer, >>>> Amrith, and have a high-bandwidth conversation about how you're >>>> wrong. :P >>>> >>> >>> >>> Jay and I chatted and it took a long time to come to an agreement >>> because we weren't able to find any beer. >>> >>> Here's what I think we've agreed about. The library will store data in >>> two tables; >>> >>> 1. the detail table which stores the individual claims and the resource >>> class. >>> 2. a generation table which stores the resource class and a generation. >>> >>> When a claim is received, the requestor performs the following >>> operations. >>> >>> begin >>> >>> select sum(detail.claims) as total_claims, >>> generation.resource as resource, >>> generation.generation last_generation >>> from detail, generation >>> where detail.resource = generation.resource >>> and generation.resource =<chosen resource; memory, cpu, ...> >>> group by generation.generation, generation.resource >>> >>> if total_claims + this_claim< limit >>> insert into detail values (this_claim, resource) >>> >>> update generation >>> set generation = generation + 1 >>> where generation = last_generation >>> >>> if @@rowcount = 1 >>> -- all good >>> commit >>> else >>> rollback >>> -- try again >>> >>> >>> >>> There will be some bootstrapping that will be required for the situation >>> where there are no detail records for a given resource and so on but I >>> think we can figure that out easily. The easiest way I can think of >>> doing that is to lose the join and do both the queries (one against the >>> detail and one against the generation table within the same >>> transaction). >>> >>> Using the generation table update as the locking mechanism that prevents >>> multiple requestors from making concurrent claims. >>> >>> So long as people don't go and try and read these tables and change >>> tables outside of the methods that the library provides, we can >>> guarantee that this is al safe and will not oversubscribe. >>> >>> -amrith >>> >>> Comments inline. >>>> >>>> On 04/23/2016 11:25 AM, Amrith Kumar wrote: >>>> >>>>> On Sat, 2016-04-23 at 10:26 -0400, Andrew Laski wrote: >>>>> >>>>>> On Fri, Apr 22, 2016, at 09:57 PM, Tim Bell wrote: >>>>>> >>>>>> I have reservations on f and g. >>>>>>> >>>>>>> >>>>>>> On f., We have had a number of discussions in the past about >>>>>>> centralising quota (e.g. Boson) and the project teams of the other >>>>>>> components wanted to keep the quota contents ‘close’. This can >>>>>>> always be reviewed further with them but I would hope for at least >>>>>>> >>>>>> a >>>> >>>>> standard schema structure of tables in each project for the >>>>>>> >>>>>> handling >>>> >>>>> of quota. >>>>>>> >>>>>>> >>>>>>> On g., aren’t all projects now nested projects ? If we have the >>>>>>> complexity of handling nested projects sorted out in the common >>>>>>> library, is there a reason why a project would not want to support >>>>>>> nested projects ? >>>>>>> >>>>>>> >>>>>>> One other issue is how to do reconcilliation, each project needs >>>>>>> >>>>>> to >>>> >>>>> have a mechanism to re-calculate the current allocations and >>>>>>> reconcile that with the quota usage. While in an ideal world, this >>>>>>> should not be necessary, it would be for the foreseeable future, >>>>>>> especially with a new implementation. >>>>>>> >>>>>>> One of the big reasons that Jay and I have been pushing to remove >>>>>> reservations and tracking of quota in a separate place than the >>>>>> resources are actually used, e.g., an instance record in the Nova >>>>>> >>>>> db, >>>> >>>>> is so that reconciliation is not necessary. For example, if RAM >>>>>> >>>>> quota >>>> >>>>> usage is simply tracked as sum(instances.memory_mb) then you can be >>>>>> sure that usage is always up to date. >>>>>> >>>>> Uh oh, there be gremlins here ... >>>>> >>>>> I am positive that this will NOT work, see earlier conversations >>>>> >>>> about >>>> >>>>> isolation levels, and Jay's alternate solution. >>>>> >>>>> The way (I understand the issue, and Jay's solution) you get around >>>>> >>>> the >>>> >>>>> isolation levels trap is to NOT do your quota determinations based >>>>> >>>> on a >>>> >>>>> SUM(column) but rather based on the rowcount on a well crafted >>>>> >>>> UPDATE of >>>> >>>>> a single table that stored total quota. >>>>> >>>> No, we would do our quota calculations by doing a SUM(used) against >>>> the >>>> allocations table. There is no separate table that stored the total >>>> quota (or quota usage records). That's the source of the problem with >>>> the existing quota handling code in Nova. The generation field value >>>> is >>>> used to provide the consistent view of the actual resource usage >>>> records >>>> so that the INSERT operations for all claimed resources can be done in >>>> a >>>> transactional manner and will be rolled back if any other writer >>>> changes >>>> the amount of consumed resources on a provider (which of course would >>>> affect the quota check calculations). >>>> >>>> > You could also store a detail >>>> >>>>> claim record for each claim in an independent table that is >>>>> >>>> maintained >>>> >>>>> in the same database transaction if you so desire, that is optional. >>>>> >>>> The allocations table is the "detail claim record" table that you >>>> refer >>>> to above. >>>> >>>> My view of how this would work (which I described earlier as >>>>> >>>> building on >>>> >>>>> Jay's solution) is that the claim flow would look like this: >>>>> >>>>> select total_used, generation >>>>> from quota_claimed >>>>> where tenant =<tenant> and resource = 'memory' >>>>> >>>> There is no need to keep a total_used value for anything. That is >>>> denormalized calculated data that merely adds a point of race >>>> contention. The quota check is against the *detail* table >>>> (allocations), >>>> which stores the *actual resource usage records*. >>>> >>>> begin transaction >>>>> >>>>> update quota_claimed >>>>> set total_used = total_used + claim, generation = >>>>> generation + 1 >>>>> where tenant =<tenant> and resource = 'memory' >>>>> and generation = generation >>>>> and total_used + claim< limit >>>>> >>>> This part of the transaction must always occur **after** the >>>> insertion >>>> of the actual resource records, not before. >>>> >>>> if @@rowcount = 1 >>>>> -- optional claim_detail table >>>>> insert into claim_detail values (<tenant>, >>>>> >>>> 'memory', >>>> >>>>> claim, ...) >>>>> commit >>>>> else >>>>> rollback >>>>> >>>> So, in pseudo-Python-SQLish code, my solution works like this: >>>> >>>> limits = get_limits_from_delimiter() >>>> requested = get_requested_from_request_spec() >>>> >>>> while True: >>>> >>>> used := SELECT >>>> resource_class, >>>> resource_provider, >>>> generation, >>>> SUM(used) as total_used >>>> FROM allocations >>>> JOIN resource_providers ON (...) >>>> WHERE consumer_uuid = $USER_UUID >>>> GROUP BY >>>> resource_class, >>>> resource_provider, >>>> generation; >>>> >>>> # Check that our requested resource amounts don't exceed quotas >>>> if not check_requested_within_limits(requested, used, limits): >>>> raise QuotaExceeded >>>> >>>> # Claim all requested resources. Note that the generation >>>> retrieved >>>> # from the above query is our consistent view marker. If the >>>> UPDATE >>>> # below succeeds and returns != 0 rows affected, that means there >>>> # was no other writer that changed our resource usage in between >>>> # this thread's claiming of resources, and therefore we prevent >>>> # any oversubscription of resources. >>>> begin_transaction: >>>> >>>> provider := SELECT id, generation, ... FROM >>>> resource_providers >>>> JOIN (...) >>>> WHERE (<resource_usage_filters>) >>>> >>>> for resource in requested: >>>> INSERT INTO allocations ( >>>> resource_provider_id, >>>> resource_class_id, >>>> consumer_uuid, >>>> used >>>> ) VALUES ( >>>> $provider.id, >>>> $resource.id, >>>> $USER_UUID, >>>> $resource.amount >>>> ); >>>> >>>> rows_affected := UPDATE resource_providers >>>> SET generation = generation + 1 >>>> WHERE id = $provider.id >>>> AND generation = >>>> $used[$provider.id].generation; >>>> >>>> if $rows_affected == 0: >>>> ROLLBACK; >>>> >>>> The only reason we would need a post-claim quota check is if some of >>>> the >>>> requested resources are owned and tracked by an external-to-Nova >>>> system. >>>> >>>> BTW, note to Ed Leafe... unless your distributed data store supports >>>> transactional semantics, you can't use a distributed data store for >>>> these types of solutions. Instead, you will need to write a whole >>>> bunch >>>> of code that does post-auditing of claims and quotas and a system >>>> that >>>> accepts that oversubscription and out-of-sync quota limits and usages >>>> is >>>> a fact of life. Not to mention needing to implement JOINs in Python. >>>> >>>> But, it is my understanding that >>>>> >>>>> (a) if you wish to do the SUM(column) approach that you >>>>> >>>> propose, >>>> >>>>> you must have a reservation that is committed and then you >>>>> >>>> must >>>> >>>>> re-read the SUM(column) to make sure you did not >>>>> >>>> over-subscribe; >>>> >>>>> and >>>>> >>>> Erm, kind of? Oversubscription is not possible in the solution I >>>> describe because the compare-and-update on the >>>> resource_providers.generation field allows for a consistent view of >>>> the >>>> resources used -- and if that view changes during the insertion of >>>> resource usage records -- the transaction containing those insertions >>>> is >>>> rolled back. >>>> >>>> (b) to get away from reservations you must stop using the >>>>> SUM(column) approach and instead use a single quota_claimed >>>>> table to determine the current quota claimed. >>>>> >>>> No. This has nothing to do with reservations. >>>> >>>> At least that's what I understand of Jay's example from earlier in >>>>> >>>> this >>>> >>>>> thread. >>>>> >>>>> Let's definitely discuss this in Austin. While I don't love Jay's >>>>> solution for other reasons to do with making the quota table a >>>>> >>>> hotspot >>>> >>>>> and things like that, it is a perfectly workable solution, I think. >>>>> >>>> There is no quota table in my solution. >>>> >>>> If you refer to the resource_providers table (the table that has the >>>> generation field), then yes, it's a hot spot. But hot spots in the DB >>>> aren't necessarily a bad thing if you design the underlying schema >>>> properly. >>>> >>>> More in Austin. >>>> >>>> Best, >>>> -jay >>>> >>>> >>>>>> Tim >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Amrith Kumar<amr...@tesora.com> >>>>>>> Reply-To: "OpenStack Development Mailing List (not for usage >>>>>>> questions)"<openstack-dev@lists.openstack.org> >>>>>>> Date: Friday 22 April 2016 at 06:51 >>>>>>> To: "OpenStack Development Mailing List (not for usage questions)" >>>>>>> <openstack-dev@lists.openstack.org> >>>>>>> Subject: Re: [openstack-dev] More on the topic of DELIMITER, the >>>>>>> Quota Management Library proposal >>>>>>> >>>>>>> >>>>>>> >>>>>>> I’ve thought more about Jay’s approach to enforcing >>>>>>> >>>>>> quotas >>>> >>>>> and I think we can build on and around it. With that >>>>>>> implementation as the basic quota primitive, I think we >>>>>>> >>>>>> can >>>> >>>>> build a quota management API that isn’t dependent on >>>>>>> reservations. It does place some burdens on the consuming >>>>>>> projects that I had hoped to avoid and these will cause >>>>>>> heartburn for some (make sure that you always request >>>>>>> resources in a consistent order and free them in a >>>>>>> consistent order being the most obvious). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> If it doesn’t make it harder, I would like to see if we >>>>>>> >>>>>> can >>>> >>>>> make the quota API take care of the ordering of requests. >>>>>>> i.e. if the quota API is an extension of Jay’s example >>>>>>> >>>>>> and >>>> >>>>> accepts some data structure (dict?) with all the claims >>>>>>> >>>>>> that >>>> >>>>> a project wants to make for some operation, and then >>>>>>> proceeds to make those claims for the project in the >>>>>>> consistent order, I think it would be of some value. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Beyond that, I’m on board with a-g below, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -amrith >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Vilobh Meshram >>>>>>> [mailto:vilobhmeshram.openst...@gmail.com] >>>>>>> Sent: Friday, April 22, 2016 4:08 AM >>>>>>> To: OpenStack Development Mailing List (not for usage >>>>>>> questions)<openstack-dev@lists.openstack.org> >>>>>>> Subject: Re: [openstack-dev] More on the topic of >>>>>>> >>>>>> DELIMITER, >>>> >>>>> the Quota Management Library proposal >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I strongly agree with Jay on the points related to "no >>>>>>> reservation" , keeping the interface simple and the role >>>>>>> >>>>>> for >>>> >>>>> Delimiter (impose limits on resource consumption and >>>>>>> >>>>>> enforce >>>> >>>>> quotas). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The point to keep user quota, tenant quotas in Keystone >>>>>>> sounds interestring and would need support from Keystone >>>>>>> team. We have a Cross project session planned [1] and >>>>>>> >>>>>> will >>>> >>>>> definitely bring that up in that session. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The main thought with which Delimiter was formed was to >>>>>>> enforce resource quota in transaction safe manner and do >>>>>>> >>>>>> it >>>> >>>>> in a cross-project conducive manner and it still holds >>>>>>> true. Delimiters mission is to impose limits on >>>>>>> resource consumption and enforce quotas in transaction >>>>>>> >>>>>> safe >>>> >>>>> manner. Few key aspects of Delimiter are :- >>>>>>> >>>>>>> >>>>>>> >>>>>>> a. Delimiter will be a new Library and not a Service. >>>>>>> Details covered in spec. >>>>>>> >>>>>>> >>>>>>> b. Delimiter's role will be to impose limits on resource >>>>>>> consumption. >>>>>>> >>>>>>> >>>>>>> c. Delimiter will not be responsible for rate limiting. >>>>>>> >>>>>>> >>>>>>> d. Delimiter will not maintain data for the resources. >>>>>>> Respective projects will take care of keeping, >>>>>>> >>>>>> maintaining >>>> >>>>> data for the resources and resource consumption. >>>>>>> >>>>>>> >>>>>>> e. Delimiter will not have the concept of "reservations". >>>>>>> Delimiter will read or update the "actual" resource >>>>>>> >>>>>> tables >>>> >>>>> and will not rely on the "cached" tables. At present, the >>>>>>> quota infrastructure in Nova, Cinder and other projects >>>>>>> >>>>>> have >>>> >>>>> tables such as reservations, quota_usage, etc which are >>>>>>> >>>>>> used >>>> >>>>> as "cached tables" to track re >>>>>>> >>>>>>> >>>>>>> f. Delimiter will fetch the information for project >>>>>>> >>>>>> quota, >>>> >>>>> user quota from a centralized place, say Keystone, or if >>>>>>> that doesn't materialize will fetch default quota values >>>>>>> from respective service. This information will be cached >>>>>>> since it gets updated rarely but read many times. >>>>>>> >>>>>>> >>>>>>> g. Delimiter will take into consideration whether the >>>>>>> project is a Flat or Nested and will make the >>>>>>> >>>>>> calculations >>>> >>>>> of allocated, available resources. Nested means project >>>>>>> namespace is hierarchical and Flat means project >>>>>>> >>>>>> namespace >>>> >>>>> is not hierarchical. >>>>>>> >>>>>>> >>>>>>> -Vilobh >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> >>>>>> >>>> https://www.openstack.org/summit/austin-2016/summit-schedule/events/9492 >>>> >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 21, 2016 at 11:08 PM, Joshua Harlow >>>>>>> <harlo...@fastmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> Since people will be on a plane soon, >>>>>>> >>>>>>> I threw this together as a example of a quota >>>>>>> >>>>>> engine >>>> >>>>> (the zookeeper code does even work, and yes it >>>>>>> provides transactional semantics due to the nice >>>>>>> abilities of zookeeper znode versions[1] and its >>>>>>> inherent consistency model, yippe). >>>>>>> >>>>>>> >>>>>>> https://gist.github.com/harlowja/e7175c2d76e020a82ae94467a1441d85 >>>> >>>>> Someone else can fill in the db quota engine with >>>>>>> >>>>>> a >>>> >>>>> similar/equivalent api if they so dare, ha. Or >>>>>>> >>>>>> even >>>> >>>>> feel to say the gist/api above is crap, cause >>>>>>> >>>>>> that's >>>> >>>>> ok to, lol. >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> >>>> https://zookeeper.apache.org/doc/r3.1.2/zookeeperProgrammers.html#Data >>>> +Access >>>> >>>>> >>>>>>> >>>>>>> Amrith Kumar wrote: >>>>>>> >>>>>>> Inline below ... thread is too long, will >>>>>>> catch you in Austin. >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jay Pipes >>>>>>> [mailto:jaypi...@gmail.com] >>>>>>> Sent: Thursday, April 21, 2016 >>>>>>> >>>>>> 8:08 >>>> >>>>> PM >>>>>>> To: >>>>>>> openstack-dev@lists.openstack.org >>>>>>> Subject: Re: [openstack-dev] More >>>>>>> >>>>>> on >>>> >>>>> the topic of DELIMITER, the Quota >>>>>>> Management Library proposal >>>>>>> >>>>>>> Hmm, where do I start... I think >>>>>>> >>>>>> I >>>> >>>>> will just cut to the two primary >>>>>>> disagreements I have. And I will >>>>>>> top-post because this email is >>>>>>> >>>>>> way >>>> >>>>> too >>>>>>> big. >>>>>>> >>>>>>> 1) On serializable isolation >>>>>>> >>>>>> level. >>>> >>>>> No, you don't need it at all to >>>>>>> prevent races in claiming. Just >>>>>>> >>>>>> use >>>> >>>>> a >>>>>>> compare-and-update with retries >>>>>>> strategy. Proof is here: >>>>>>> >>>>>>> >>>>>>> >>>> https://github.com/jaypipes/placement-bench/blob/master/placement.py#L97- >>>> >>>> L142 >>>>>>> >>>>>>> Works great and prevents multiple >>>>>>> writers from oversubscribing any >>>>>>> resource without relying on any >>>>>>> particular isolation level at >>>>>>> >>>>>> all. >>>> >>>>> The `generation` field in the >>>>>>> inventories table is what allows >>>>>>> multiple >>>>>>> writers to ensure a consistent >>>>>>> >>>>>> view >>>> >>>>> of the data without needing to >>>>>>> >>>>>> rely >>>> >>>>> on >>>>>>> heavy lock-based semantics and/or >>>>>>> RDBMS-specific isolation levels. >>>>>>> >>>>>>> >>>>>>> >>>>>>> [amrith] this works for what it is doing, >>>>>>> >>>>>> we >>>> >>>>> can definitely do this. This will work at >>>>>>> any isolation level, yes. I didn't want >>>>>>> >>>>>> to >>>> >>>>> go this route because it is going to >>>>>>> >>>>>> still >>>> >>>>> require an insert into another table >>>>>>> recording what the actual 'thing' is that >>>>>>> >>>>>> is >>>> >>>>> claiming the resource and that insert is >>>>>>> going to be in a different transaction >>>>>>> >>>>>> and >>>> >>>>> managing those two transactions was what >>>>>>> >>>>>> I >>>> >>>>> wanted to avoid. I was hoping to avoid >>>>>>> having two tables tracking claims, one >>>>>>> showing the currently claimed quota and >>>>>>> another holding the things that claimed >>>>>>> >>>>>> that >>>> >>>>> quota. Have to think again whether that >>>>>>> >>>>>> is >>>> >>>>> possible. >>>>>>> >>>>>>> 2) On reservations. >>>>>>> >>>>>>> The reason I don't believe >>>>>>> reservations are necessary to be >>>>>>> >>>>>> in >>>> >>>>> a quota >>>>>>> library is because reservations >>>>>>> >>>>>> add >>>> >>>>> a concept of a time to a claim of >>>>>>> some >>>>>>> resource. You reserve some >>>>>>> >>>>>> resource >>>> >>>>> to be claimed at some point in >>>>>>> >>>>>> the >>>> >>>>> future and release those >>>>>>> >>>>>> resources >>>> >>>>> at a point further in time. >>>>>>> >>>>>>> Quota checking doesn't look at >>>>>>> >>>>>> what >>>> >>>>> the state of some system will be >>>>>>> >>>>>> at >>>> >>>>> some point in the future. It >>>>>>> >>>>>> simply >>>> >>>>> returns whether the system *right >>>>>>> now* can handle a request *right >>>>>>> now* to claim a set of resources. >>>>>>> >>>>>>> If you want reservation semantics >>>>>>> for some resource, that's totally >>>>>>> cool, >>>>>>> but IMHO, a reservation service >>>>>>> should live outside of the >>>>>>> >>>>>> service >>>> >>>>> that is >>>>>>> actually responsible for >>>>>>> >>>>>> providing >>>> >>>>> resources to a consumer. >>>>>>> Merging right-now quota checks >>>>>>> >>>>>> and >>>> >>>>> future-based reservations into >>>>>>> >>>>>> the >>>> >>>>> same >>>>>>> library just complicates things >>>>>>> unnecessarily IMHO. >>>>>>> >>>>>>> >>>>>>> >>>>>>> [amrith] extension of the above ... >>>>>>> >>>>>>> 3) On resizes. >>>>>>> >>>>>>> Look, I recognize some users see >>>>>>> some value in resizing their >>>>>>> resources. >>>>>>> That's fine. I personally think >>>>>>> expand operations are fine, and >>>>>>> >>>>>> that >>>> >>>>> shrink operations are really the >>>>>>> operations that should be >>>>>>> >>>>>> prohibited >>>> >>>>> in >>>>>>> the API. But, whatever, I'm fine >>>>>>> with resizing of requested >>>>>>> >>>>>> resource >>>> >>>>> amounts. My big point is if you >>>>>>> don't have a separate table that >>>>>>> stores >>>>>>> quota_usages and instead only >>>>>>> >>>>>> have a >>>> >>>>> single table that stores the >>>>>>> >>>>>> actual >>>> >>>>> resource usage records, you don't >>>>>>> have to do *any* quota check >>>>>>> operations >>>>>>> at all upon deletion of a >>>>>>> >>>>>> resource. >>>> >>>>> For modifying resource amounts >>>>>>> >>>>>> (i.e. >>>> >>>>> a >>>>>>> resize) you merely need to change >>>>>>> the calculation of requested >>>>>>> resource >>>>>>> amounts to account for the >>>>>>> already-consumed usage amount. >>>>>>> >>>>>>> Bottom line for me: I really >>>>>>> >>>>>> won't >>>> >>>>> support any proposal for a >>>>>>> >>>>>> complex >>>> >>>>> library that takes the resource >>>>>>> claim process out of the hands of >>>>>>> the >>>>>>> services that own those >>>>>>> >>>>>> resources. >>>> >>>>> The simpler the interface of this >>>>>>> library, the better. >>>>>>> >>>>>>> >>>>>>> >>>>>>> [amrith] my proposal would not but this >>>>>>> email thread has got too long. Yes, >>>>>>> >>>>>> simpler >>>> >>>>> interface, will catch you in Austin. >>>>>>> >>>>>>> Best, >>>>>>> -jay >>>>>>> >>>>>>> On 04/19/2016 09:59 PM, Amrith >>>>>>> >>>>>> Kumar >>>> >>>>> wrote: >>>>>>> >>>>>>> -----Original >>>>>>> Message----- >>>>>>> From: Jay Pipes >>>>>>> >>>>>>> [mailto:jaypi...@gmail.com] >>>> >>>>> Sent: Monday, >>>>>>> >>>>>> April >>>> >>>>> 18, 2016 2:54 PM >>>>>>> To: >>>>>>> >>>>>>> openstack-dev@lists.openstack.org >>>> >>>>> Subject: Re: >>>>>>> [openstack-dev] >>>>>>> >>>>>> More >>>> >>>>> on the topic of >>>>>>> DELIMITER, the >>>>>>> Quota Management >>>>>>> Library proposal >>>>>>> >>>>>>> On 04/16/2016 >>>>>>> >>>>>> 05:51 >>>> >>>>> PM, Amrith Kumar >>>>>>> wrote: >>>>>>> >>>>>>> If we >>>>>>> therefore >>>>>>> assume >>>>>>> >>>>>> that >>>> >>>>> this will >>>>>>> >>>>>> be >>>> >>>>> a Quota >>>>>>> >>>>>>> Management >>>> >>>>> Library, >>>>>>> it is >>>>>>> >>>>>> safe >>>> >>>>> to assume >>>>>>> that >>>>>>> >>>>>> quotas >>>> >>>>> are going >>>>>>> >>>>>> to >>>> >>>>> be >>>>>>> >>>>>> managed >>>> >>>>> on a >>>>>>> >>>>>>> per-project >>>> >>>>> basis, >>>>>>> >>>>>> where >>>> participating projects will use this library. >>>> >>>>> I believe >>>>>>> that it >>>>>>> stands to >>>>>>> reason >>>>>>> >>>>>> that >>>> >>>>> any data >>>>>>> >>>>>>> persistence >>>> >>>>> will >>>>>>> have to >>>>>>> >>>>>> be >>>> >>>>> in a >>>>>>> location >>>>>>> decided >>>>>>> >>>>>> by >>>> >>>>> the >>>>>>> >>>>>>> individual >>>> >>>>> project. >>>>>>> >>>>>>> >>>>>>> Depends on what >>>>>>> >>>>>> you >>>> >>>>> mean by "any data >>>>>>> persistence". If >>>>>>> >>>>>> you >>>> >>>>> are >>>>>>> referring to the >>>>>>> storage of quota >>>>>>> values (per user, >>>>>>> per tenant, >>>>>>> global, etc) I >>>>>>> >>>>>> think >>>> >>>>> that should be >>>>>>> >>>>>> done >>>> >>>>> by the Keystone >>>>>>> service. >>>>>>> This data is >>>>>>> essentially an >>>>>>> attribute of the >>>>>>> user or the >>>>>>> >>>>>> tenant >>>> >>>>> or the >>>>>>> >>>>>>> >>>>>>> service endpoint itself (i.e. >>>>>>> >>>>>>> >>>>>>> global defaults). >>>>>>> This data also >>>>>>> rarely changes >>>>>>> >>>>>> and >>>> >>>>> logically belongs >>>>>>> to the service >>>>>>> >>>>>> that >>>> >>>>> manages users, >>>>>>> tenants, and >>>>>>> >>>>>> service >>>> >>>>> endpoints: >>>>>>> >>>>>>> >>>>>>> Keystone. >>>>>>> >>>>>>> >>>>>>> If you are >>>>>>> >>>>>> referring >>>> >>>>> to the storage of >>>>>>> resource usage >>>>>>> records, yes, >>>>>>> each service >>>>>>> >>>>>> project >>>> >>>>> should own that >>>>>>> >>>>>> data >>>> >>>>> (and frankly, I >>>>>>> don't see a >>>>>>> need to persist >>>>>>> >>>>>> any >>>> >>>>> quota usage data >>>>>>> >>>>>> at >>>> >>>>> all, as I >>>>>>> >>>>>> mentioned >>>> >>>>> in a >>>>>>> previous reply to >>>>>>> Attila). >>>>>>> >>>>>>> >>>>>>> [amrith] You make a >>>>>>> distinction that I had >>>>>>> >>>>>> made >>>> >>>>> implicitly, and it is >>>>>>> important to highlight >>>>>>> >>>>>> it. >>>> >>>>> Thanks for pointing it >>>>>>> >>>>>> out. >>>> >>>>> Yes, I meant >>>>>> >>>>>>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
