Open Stack

All I can say at the moment is that Usage and Quota management is a crappy
thing to do in OpenStack. Every service has it's own way of doing it both
in clients and api's. +n+ for making a effort in standardizing this thing
in a way that could be alike across projects..

2014-11-19 14:33 GMT+01:00 Sylvain Bauza <sbauza at redhat.com>:

>
> 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/75ef3930/attachment.html>