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 <henriquecostatr...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
