Open Stack

On 04/05/16 20:35, "Nikhil Komawar" <nik.komawar at gmail.com> wrote:

>
>
>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.


With Glance not having quotas (and a reasonable set of defaults), I think we can make the use of the delimiter functionalities
optional for Glance at the beginning and thus is a much easier use case than those who have to convert the existing combinations 
of user/project/nested project quotas for production clouds. A release cycle with Glance quotas in production would also encourage
further adoption going forward.

I would like that nested quotas is not a special case as we deploy delimeter, just business as usual. There are so many varied use cases and flexibility for 
those who do not need it to make it the standard deployment for delimeter. Clearly, existing installs would need to find a migration
path but generally, these would not be nested deployments.

A single oslo library gives a good chance to get a consistent implementation across multiple OpenStack components. This would massively 
simplify the operator and resource manager use cases.

Tim


>
>>>
>>> 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
>
>
>__________________________________________________________________________
>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