Open Stack

Comments inline.


On 5/4/16 2:58 PM, Tim Bell wrote:
>
> 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 was of the differing opinion wrt to using delimiter's functionalities,
mostly because the lib can and should be configured by the service in a
way the service is setup to be used in keystone -- for nested lib's
nested driver would be used and for flat quotas it's flat driver. Given
the implementation will use some sort of if logic that will read
hierarchy, it would make sense to use the config in the service to use
hierarchical or non-hierarchical driver.

This would allow both existing deployments that do not have complex
hierarchy to use the library and to the new ones that have hierarchy
setup & prefer to use quota out of the box in hierarchical manner. From
the input I gather talking to a bunch of people, the difference between
adding simple quota or hierarchical quota is not significantly larger
than adding the entire functionality in a service (like Glance that
doesn't have quotas). As delimiter is an attempt to solve the
consistency, things should work pretty smoothly for services like Glance.

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

I am not sure how far we can draw the line for seamless workflow for
delimiter. The spec [5] mentions on line 198 that default case would be
flat but the existing Glance deployments would be assuming 'Independent
quotas' (comment on line 86). Also, I am looking forward to next meeting
where we can get better picture of the layout of this library.

Basically, I'm saying we need to handle that logic in delimiter anyway
-- either today or later when the usage of the library happens. The risk
of having to migrate 100s of (tenants) projects and may be order of 100K
or more images is what is really scary. Operators do say they have a
massive amount of data in Glance tables -- that makes things worse as we
get requests for support of not just image-data storage quotas but of
#images, #properties, #members, etc. Looks to me like a impossible
migration :/

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

+1

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