[Openstack-operators] Are cells what I want here?
jon at jonproulx.com
Fri Jul 12 19:25:06 UTC 2013
On Fri, Jul 12, 2013 at 2:43 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> Really interesting solution, Chris. Thanks for sharing! I had not thought
> of that, but it certainly makes sense on paper.
> On 07/12/2013 02:22 PM, Chris Behrens wrote:
>> It was said that your quota issue is not solved by cells… but I'm not
>> actually sure that is true. This is certainly not the normal way I
>> would configure cells, but I suppose it's possible to do this:
>> 1) Use the NoopQuotaDriver in your API cell.
>> 2) Use the normal DbQuotaDriver in childs cells.
>> Anyway, I only recommend trying this if you want to live slightly
>> dangerously. :)
I can take some danger (cells are still documented as "experimental"), and
this is academia over here.
The quotas in the child cells would be invisible to tenants, wouldn't they?
This is somewhat less than ideal.
Given what I'm hearing, my current thought is to use host aggregates with
aggregate specific flavors and a custom scheduler filter that gets
cpu_allocation_ratio and ram_allocation_ratio from aggregate metadata and
uses the regular conf values as defaults.
That gets me most of the way. Haven't looked at the code for this part but
hopefully a similar bit of custom coding can get me
compute_fill_first_cost_fn_weight as a aggregate settable value rather than
a global value.
Making the huge leap of faith that that all works, it leaves quota.
Everything here feels kludgy, but simplest kludge that comes to mind is
forcing different tenants for each "value" or resource, which can then have
different quotas and using flavor-access list to restrict high value
This is a little bumpy on the user end but perhaps livable, and discourages
using the high value systems which is OK given my nonexistent revenue
model. Given physical and 1:1 virtualised systems have essentially the same
value per resource unit to me, I's only need 2 value levels which I think
would work though I don't think it would go much past that. For example
adding baremetal with GPUs as the 3rd value level and set of tenants would
probably be too much.
Guess it's time to make some PoC systems and see what catches fire and what
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators