Open Stack

On 2/5/2018 11:44 PM, Massimo Sgaravatto wrote:
> But if I try to specify the long list of projects, I get:a "Value ... is 
> too long" error message [*].
> 
> I can see two workarounds for this problem:
> 
> 1) Create an host aggregate per project:
> 
> HA1 including CA1, C2, ... Cx and with filter_tenant_id=p1
> HA2 including CA1, C2, ... Cx and with filter_tenant_id=p2
> etc
> 
> 2) Use the AggregateInstanceExtraSpecsFilter, creating two aggregates 
> and having each flavor visible only by a set of projects, and tagged 
> with a specific string that should match the value specified in the 
> correspondent host aggregate
> 
> Is this correct ? Can you see better options ?

This problem came up in the public cloud WG meeting at the PTG last week.

The issue is that the host aggregate metadata value is limited to 255 
characters so you're pretty severely restricted in the number of 
projects you can isolate to that host aggregate.

There were two ideas that I remember getting discussed for possible 
solutions:

1. The filter could grow support for domains (or some other fancy 
keystone construct) such that you could nest projects and then just 
isolate the root project/domain to that host aggregate. I'm not sharp on 
keystone stuff so would need more input here, but this might not be a 
great solution if nova has to ask keystone for this information per run 
through the filters - that could get expensive. If the information is in 
the user request context (token) then maybe that would work.

2. Dan Smith mentioned another idea such that we could index the 
aggregate metadata keys like filter_tenant_id0, filter_tenant_id1, ... 
filter_tenant_idN and then combine those so you have one host aggregate 
filter_tenant_id* key per tenant.

-- 

Thanks,

Matt