Open Stack

On Nov 19, 2014, at 9:51 AM, Sylvain Bauza <sbauza at redhat.com> wrote:

> 
> Le 19/11/2014 15:06, Doug Hellmann a écrit :
>> On Nov 19, 2014, at 8:33 AM, Sylvain Bauza <sbauza at redhat.com> wrote:
>> 
>>> Le 18/11/2014 20:05, Doug Hellmann a écrit :
>>>> On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:
>>>> 
>>>>> On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:
>>>>>> I’ve spent a bit of time thinking about the resource ownership issue.
>>>>>> The challenge there is we don’t currently have any libraries that
>>>>>> define tables in the schema of an application. I think that’s a good
>>>>>> pattern to maintain, since it avoids introducing a lot of tricky
>>>>>> issues like how to manage migrations for the library, how to ensure
>>>>>> they are run by the application, etc. The fact that this common quota
>>>>>> thing needs to store some data in a schema that it controls says to me
>>>>>> that it is really an app and not a library. Making the quota manager
>>>>>> an app solves the API definition issue, too, since we can describe a
>>>>>> generic way to configure quotas and other applications can then use
>>>>>> that API to define specific rules using the quota manager’s API.
>>>>>> 
>>>>>> I don’t know if we need a new application or if it would make sense
>>>>>> to, as with policy, add quota management features to keystone. A
>>>>>> single well-defined app has some appeal, but there’s also a certain
>>>>>> amount of extra ramp-up time needed to go that route that we wouldn’t
>>>>>> need if we added the features directly to keystone.
>>>>> I'll also point out that it was largely because of the storage needs
>>>>> that I chose to propose Boson[1] as a separate app, rather than as a
>>>>> library.  Further, the dimensions over which quota-covered resources
>>>>> needed to be tracked seemed to me to be complicated enough that it would
>>>>> be better to define a new app and make it support that one domain well,
>>>>> which is why I didn't propose it as something to add to Keystone.
>>>>> Consider: nova has quotas that are applied by user, other quotas that
>>>>> are applied by tenant, and even some quotas on what could be considered
>>>>> sub-resources—a limit on the number of security group rules per security
>>>>> group, for instance.
>>>>> 
>>>>> My current feeling is that, if we can figure out a way to make the quota
>>>>> problem into an acceptable library, that will work; it would probably
>>>>> have to maintain its own database separate from the client app and have
>>>>> features for automatically managing the schema, since we couldn't
>>>>> necessarily rely on the client app to invoke the proper juju there.  If,
>>>>> on the other hand, that ends up failing, then the best route is probably
>>>>> to begin by developing a separate app, like Boson, as a PoC; then, after
>>>>> we have some idea of just how difficult it is to actually solve the
>>>>> problem, we can evaluate whether it makes sense to actually fold it into
>>>>> a service like Keystone, or whether it should stand on its own.
>>>>> 
>>>>> (Personally, I think Boson should be created and should stand on its
>>>>> own, but I also envision using it for purposes outside of OpenStack…)
>>>> Thanks for mentioning Boson again. I’m embarrassed that I completely forgot about the fact that you mentioned this at the summit.
>>>> 
>>>> I’ll have to look at the proposal more closely before I comment in any detail, but I take it as a good sign that we’re coming back around to the idea of solving this with an app instead of a library.
>>> I assume I'm really late in the thread so I can just sit and give +1 to this direction : IMHO, quotas need to managed thanks to a CRUD interface which implies to get an app, as it sounds unreasonable to extend each consumer app API.
>>> 
>>> That said, back to Blazar, I just would like to emphasize that Blazar is not trying to address the quota enforcement level, but rather provide a centralized endpoint for managing reservations.
>>> Consequently, Blazar can also be considered as a consumer of this quota system, whatever it's in a library or on a separate REST API.
>>> 
>>> Last thing, I don't think that a quota application necessarly means that quotas enforcement should be managed thanks to external calls to this app. I can rather see an external system able to set for each project a local view of what should be enforced locally. If operators don't want to deploy that quota management project, it's up to them to address the hetergenous setups for each project.
>> I’m not sure what this means. You want the new service to be optional? How would apps written against the service find and manage quota data if the service isn’t there?
> 
> My bad. Let me rephrase it. I'm seeing this service as providing added value for managing quotas by ensuring consistency across all projects. But as I said, I'm also thinking that the quota enforcement has still to be done at the customer project level.

Oh, yes, that is true. I envision the API for the new service having a call that means “try to consume X units of a given quota” and that it would return information about whether that can be done. The apps would have to define what quotas they care about, and make the appropriate calls.

> 
> So, I can imagine a client (or a Facade if you prefer) providing quota resources to the customer app which could be either fetched (thru some caching) from the service, or directly taken from the existing quota DB.

I’m not sure we want both solutions. We need to consider a migration path, but for simplicity’s sake if we’re going to create a new quota service we should just use that and not also have a separate built-in implementation.

> 
> In order to do that, I could imagine those steps :
> #1 : customer app makes use of oslo.quota for managing its own quota resources
> #2 : the external app provides a client able to either query the app or make use of oslo.quota for looking inside
> #43 : the customer app changes its current usage of oslo.quota to the external app client
> 
> 
> Let me know if you need futher details.
> -Sylvain
> 
>> Doug
>> 
>>> My 2 cts (too),
>>> -Sylvain
>>> 
>>>> Doug
>>>> 
>>>>> Just my $.02…
>>>>> 
>>>>> [1] https://wiki.openstack.org/wiki/Boson
>>>>> -- 
>>>>> Kevin L. Mitchell <kevin.mitchell at rackspace.com>
>>>>> Rackspace
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev