Open Stack

On 5/4/16 2:09 PM, Tim Bell wrote:
>
> On 04/05/16 19:41, "Nikhil Komawar" <nik.komawar at gmail.com> wrote:
>
>> Thanks for the summary and taking care of the setup, Vilobh!
>>
>> Pretty meticulously written on what was agreed at the session. Kudos!
>>
>> I wanted to add some points that were asked during the Glance
>> contributors' meetup:
>>
>> * The quota limits will be set on the tables in the service that
>> maintains the resources for each individual resource (not in keystone).
>> The default value is what is picked from the config. I think over time
>> we will come up with implementation detail on how the hierarchical
>> default value should be set.
>>
>> * The quota allocation calculation will be based on the project
>> hierarchy in consideration (given that driver is being used in such
>> deployment scenario) and the usage for that resource recorded in the
>> resource's quota table in that service. So, this will involve
>> interaction with keystone and within the quota table in the project.
>>
>> * We will be working on a migration story separately (outside of the
>> library). Delimiter does not own the quota limits and usage data so it
>> will not deal with migrations.
> Given that Glance does not currently have a quota, it may be possible to use this as the initial implementation. This would also avoid a later migration effort.
>
> Tim
>
>

Thanks for the response Tim. I am of the same opinion but haven't really
internalized this migration path as I've not been on the deploy-er side
of managing quota yet. Intuitively migration for quotas seems like a
terrible experience, possibly going over days?

I presume that nested quota support, if built in from get go, when the
tables are set is probably the best idea of hierarchical quota support.
Hoping that's not overly pessimistic assumption.

>>
>> On 5/4/16 1:23 PM, Vilobh Meshram wrote:
>>> Hi All,
>>>
>>> For people who missed the design summit session on Delimiter - Cross
>>> project Quota enforcement library here is a gist of what we discussed.
>>> Etherpad [1] captures the details. 
>>>
>>> 1. Delimiter will not be responsible for rate-limiting.
>>> 2. Delimiter will not maintain data for the projects.
>>> 3. Delimiter will not have the concept of reservations.
>>> 4. Delimiter will fetch information for project quotas from respective
>>> projects.
>>> 5. Delimiter will consolidate utility code for quota related issues at
>>> common place. For example X, Y, Z companies might have different
>>> scripts to fix quota issues. Delimiter can be a single place for it
>>> and the scripts can be more generalized to suit everyones needs.
>>> 6. The details of project hierarchy is maintained in Keystone but
>>> Delimiter while making calculations for available/free resource will
>>> take into consideration whether the project has flat or nested hierarchy.
>>> 7. Delimiter will rely on the concept of generation-id to guarantee
>>> sequencing. Generation-id gives a point in time view of resource usage
>>> in a project. Project consuming delimiter will need to provide this
>>> information while checking or consuming quota. At present Nova [3] has
>>> the concept of generation-id.
>>> 8. Spec [5] will be modified based on the design summit discussion.
>>>
>>> If you want to contribute to Delimiter, please join *#openstack-quota. *
>>>
>>> We have *meetings every Tuesday at 17:00 UTC. *Please join us !
>>> *
>>> *
>>> I am in the process of setting up a new repo for Delimiter. The
>>> launchpad page[4] is up.
>>>
>>>
>>> Thanks!
>>>
>>> -Vilobh
>>>
>>> [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
>>> [2] Slides
>>> : http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal 
>>> [3] https://review.openstack.org/#/c/283253/
>>> [4] https://launchpad.net/delimiter
>>> [5] Spec : https://review.openstack.org/#/c/284454
>>>
>>>
>>>  
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> -- 
>>
>> Thanks,
>> Nikhil
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil