Open Stack

On 09/20/2017 06:17 AM, Georgios Kaklamanos wrote:
> Hello,
> 
> Usecase: We have to deploy instances that belong in different domains,
> to different compute hosts.
> 
> Does anyone else have the same usecase? If so, how did you implement
> it?
> 
> [The rest of the mail is a more detailed explanation on the question:
> what have we tried and probable solutions that we though -- but not
> yet implemented.]
> 
> * Details
> 
> In our Openstack Deployment (Mitaka), we have to support 3 different
> domains (besides the default). We need a way to separate the compute
> hosts in three groups (aggregates), so that VMs that belong to users
> of domain A, start in group A, etc. Initially we assume that each
> compute host will belong only to one group, but that might change.
> 
> We have looked at the nova filter scheduler [1] and on the
> Aggregate_Multitenacy_Isolation filter [2], which is doing what we
> want but it works on project level (as demonstrated here [3]). Given
> that in one of our domains, we'll have at least 200 projects, we'd
> prefer to leave this as a last choice.
> 
> Modifying the above filter to make the check based on the "domain",
> isn't possible. The object that the filter receives, and contains the
> information, is the RequestSpec Object [4]. The information contained
> in its fields, doesn't include the domain_id attribute.
> 
> * Possible solutions that we've thought of:
> 
> 1. Write our own filter: Modify a filter to contain a call to
>     keystone, where it would send the project_id, and get back it's
>     domain. But this feels more like a hack than a proper solution. And
>     it might require storing the admin credentials to the node that the
>     filters are running (controller?), which we'd like to avoid.

This is actually the only viable solution. And you are already storing 
the admin credentials on the controller, since controller services like 
the conductor and API services need to contact other services.

Best,
-jay