Open Stack

Hi Henrique

I disagree with the idea that the other services should use domains. They need a concept of hierarchical ownership which we have been discussiong. Domains is one way of representing such an ownership hierarchy but i think it is too limited.

The POC code I created for hierarchical multitenancy[1] makes nova support something similar to what you want for listing projects. It needs to be extended to quotas and images, but as a concept it seems to work just fine.

There are a few remaining issues to work out around displaying the names of the hierarchy but I think this is a superior direction to adding a separate domain concept into the other services.

Vish

[1] https://github.com/vishvananda/nova/commit/ae4de19560b0a3718efaffb6c205c7a3c372412f
On Feb 19, 2014, at 4:21 AM, Henrique Truta <henriquecostatruta at gmail.com> wrote:

> Hi everyone.
>  
> It is necessary to make Nova support the Domain quotas and create a new administrative perspective. Here are some reasons why Nova should support domains:
>  
> 1 - It's interesting to keep the main Openstack components sharing the same concept, once it has already been made in Keystone. In Keystone, the domain defines more administrative boundaries and makes management of its entities easier.
>  
> 2 - Nova shouldn’t be so tied in to projects. Keystone was created to abstract concepts like these to other modules, like Nova. In addition, Nova needs to be flexible enough to work with the new functionalities that Keystone will provide. If we keep the Nova tied in to projects (or domains), we will be far from the Nova focus which is providing compute services.
>  
> 3 - There is also the Domain Quota Driver BP (https://blueprints.launchpad.net/nova/+spec/domain-quota-driver), which implementation has already began. This Blueprint allows the user to handle quotas at domain level. Nova requires domains to make this feature work properly, right above the project level. There is also an implementation that includes the domain information on the token context. This implementation have to be included as well: https://review.openstack.org/#/c/55870/ .
>  
> 4 - The Nova API must be extended in order to enable domain-level operations, that only work at project-level such as:
>     - Listing, viewing and deleting images;
>     - Deleting and listing servers;
>     - Perform server actions like changing passwords, reboot, rebuild and resize;
>     - CRUD and listing on server metadata;
> In addition to provide quota management through the API and establishment of a new administrative scope.
>  
> In order to accomplish these features, the token must contain the domain informations, which will be included as mentioned in item 3. Then, the Nova API calls will be changed to consider the domain information and when a call referent to a project is made (e.g. servers).
>  
> What do you think about it? Any additional suggestions?
>  
> Thanks.
> 
> Henrique Truta
> _______________________________________________
> 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/20140220/46bb6038/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140220/46bb6038/attachment.pgp>