← Back to team overview

openstack team mailing list archive

Re: 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-compu
te-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
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.

 

 



 

From: "Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx>
Date: Tue, 30 Aug 2011 23:04:12 +0000
To: Glen Campbell <glen.campbell@xxxxxxxxxxxxx>, Vishvananda Ishaya
<vishvananda@xxxxxxxxx>, "Nguyen, Liem Manh" <liem_m_nguyen@xxxxxx>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx" <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
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

 

 



 

From: "Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx>
Date: Tue, 30 Aug 2011 20:56:36 +0000
To: Vishvananda Ishaya <vishvananda@xxxxxxxxx>, "Nguyen, Liem Manh"
<liem_m_nguyen@xxxxxx>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx" <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] On
Behalf Of Vishvananda Ishaya
Sent: Tuesday, August 30, 2011 12:31 PM
To: Nguyen, Liem Manh
Cc: 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
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.

PNG image

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Follow ups

References