Open Stack

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:henriquecostatruta at gmail.com]
> *Sent:* Wednesday, February 19, 2014 5:21 AM
> *To:* openstack-dev at lists.openstack.org
> *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
> 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/20140219/4225f750/attachment-0001.html>