← Back to team overview

openstack team mailing list archive

Re: Nova: Admin API blueprints

 

To answer your second question, since the volumes and network stuff hasn't been fully integrated with Nova yet, I think it remains to be seen whether or not deleting all of a user's servers would actually clean up the volumes and networks associated with the user/tenant. I suspect that it would NOT, since those are essentially independent systems that are exposed via Nova. But we could certainly write a blueprint that would specify what we think should happen.

Authorization (AuthZ) is expected to be implemented by both Keystone as well as the application that uses it. Keystone would support users (per tenant) and roles, and I believe that the plan is for the application (Nova, in this case) would define what privileges are associated with each role.

I'm cc'ing Ziad, since he knows more about the AuthZ plans.



[cid:5E2A403F-DD04-4B11-AA25-835D1421DD1A]

From: "Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx<mailto:jason.rouault@xxxxxx>>
Date: Wed, 31 Aug 2011 18:34:58 +0000
To: Glen Campbell <glen.campbell@xxxxxxxxxxxxx<mailto:glen.campbell@xxxxxxxxxxxxx>>, Vishvananda Ishaya <vishvananda@xxxxxxxxx<mailto:vishvananda@xxxxxxxxx>>, "Nguyen, Liem Manh" <liem_m_nguyen@xxxxxx<mailto:liem_m_nguyen@xxxxxx>>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: RE: [Openstack] Nova: Admin API blueprints

Glen,

The API 1.1 document I am looking at does not show a GET /v1.1/{tenantId}/servers

http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/List_Servers-d1e2078.html

However, a quick test did show that things work as you suggested.

Next question:  Does deleting all the servers associated with a tenant actually clean everything up in Nova (network, volumes, etc.)?

Lastly, it appears that there is no authorization checking on who can see or do what to a tenants servers.  Is this part of the Keystone/Nova integration not yet implemented?

Thanks,

Jason

From: Glen Campbell [mailto:glen.campbell@xxxxxxxxxxxxx]
Sent: Wednesday, August 31, 2011 9:14 AM
To: Rouault, Jason (Cloud Services); Vishvananda Ishaya; Nguyen, Liem Manh
Cc: openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] Nova: Admin API blueprints

Per the API 1.1 spec, the tenant ID is part of the URL. So the actual request is not GET /servers, but GET /v1.1/{tenant/servers.

This has not been fully implemented in the past, but I believe that the latest code enforces this.


[cid:image001.png@01CC67DA.49BEBC30]

From: "Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx<mailto:jason.rouault@xxxxxx>>
Date: Tue, 30 Aug 2011 23:04:12 +0000
To: Glen Campbell <glen.campbell@xxxxxxxxxxxxx<mailto:glen.campbell@xxxxxxxxxxxxx>>, Vishvananda Ishaya <vishvananda@xxxxxxxxx<mailto:vishvananda@xxxxxxxxx>>, "Nguyen, Liem Manh" <liem_m_nguyen@xxxxxx<mailto:liem_m_nguyen@xxxxxx>>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: RE: [Openstack] Nova: Admin API blueprints

Glen,

How does one list the servers associated with a particular tenant?  When I look at the GET /servers interface it only acts on the account of the ‘caller’.

Jason

From: Glen Campbell [mailto:glen.campbell@xxxxxxxxxxxxx]
Sent: Tuesday, August 30, 2011 3:46 PM
To: Rouault, Jason (Cloud Services); Vishvananda Ishaya; Nguyen, Liem Manh
Cc: openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] Nova: Admin API blueprints

We're in the midst of implementing these now:
https://blueprints.launchpad.net/nova/+spec/admin-account-actions

Essentially suspend/resume for all servers associated with a tenant ID.

We're still having discussions around the mass deletion and whether or not we want to expose something that risky (since it's easy enough just to list the servers and delete each one). If we do, it will almost certainly occur after this:
https://blueprints.launchpad.net/nova/+spec/deferred-delete-instance


[cid:image001.png@01CC67DA.49BEBC30]

From: "Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx<mailto:jason.rouault@xxxxxx>>
Date: Tue, 30 Aug 2011 20:56:36 +0000
To: Vishvananda Ishaya <vishvananda@xxxxxxxxx<mailto:vishvananda@xxxxxxxxx>>, "Nguyen, Liem Manh" <liem_m_nguyen@xxxxxx<mailto:liem_m_nguyen@xxxxxx>>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] Nova: Admin API blueprints

And does that interface exist?

Thanks,

Jason

From: openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx<mailto:openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx> [mailto:openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Vishvananda Ishaya
Sent: Tuesday, August 30, 2011 12:31 PM
To: Nguyen, Liem Manh
Cc: openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] Nova: Admin API blueprints

With keystone in use, there is no user and project object in nova anymore.  So the only thing that would make sense inside of nova is: delete all resources associated with a  given project_id string.

Vish


On Aug 30, 2011, at 11:11 AM, Nguyen, Liem Manh wrote:




How is Nova project/user deletion handled then?  There is no synchronization for that currently.

Liem
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it.
This email may include confidential information. If you received it in error, please delete it.
This email may include confidential information. If you received it in error, please delete it.

PNG image

PNG image


Follow ups

References