Hi, all,
we've been making good progress on this blueprint:
https://blueprints.launchpad.net/nova/+spec/domain-quota-driver-api
which relies on the domain quota driver stuff. Maybe you'd like to have
a look at that as well.
Kind regards,
Ulrich
On 19.02.2014 16:45, Tiwari, Arvind wrote:
Hi Henrique,
I agree with your thoughts and in my opinion every OpenStack service
has to be Domain aware. Specially it will be more helpful in large
scale OpenStack deployments where IAM resources are scoped to a domain
but other services (e.g. Nova) are just not aware of domains.
Thanks,
Arvind
*From:*Henrique Truta [mailto:[email protected]]
*Sent:* Wednesday, February 19, 2014 5:21 AM
*To:* [email protected]
*Subject:* [openstack-dev] [Nova] Including Domains in Nova
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?
AT: Keystone also has to enforce the domain scoping more strongly, as
in the current model Keystone resources are not required to be scoped
a domain.
Thanks.
Henrique Truta
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
