Ask Your Question

How do I effectively disable/enable a tenant using the API?

asked 2013-04-25 03:11:47 -0500

Elegie gravatar image

updated 2013-05-10 18:22:06 -0500

smaffulli gravatar image

I am a Java developer interacting with OpenStack through the REST API - I am unfortunately not yet familiar with the product, but happily learning.

I have a user story by which I need to deactivate a tenant. The business case, I suppose, is pretty standard: if a user happens to not respect my company's conditions of service, then we want to block all accesses to his/her tenant(s), so that no one can access it anymore, in any of read/write mode.

I have checked out the API documentation, and found out that a tenant could be as easily enabled/disabled as setting the "enabled" property of the tenant object, using an updateTenant service call.

My problem, however, is that the setting of this property, while reported to be working by the code returned by the service call, does not happen to yield the effects that I expect. Namely, even with a disabled tenant, I can still insert some object into a container held by the tenant.

Hence my question: how do I effectively disable/enable a tenant, so as to prevent any write/read on it? Am I using the right method (and if so, why is it failing)? Should I use another approach? Could this possibly be related to some security setting (roles or tokens in use)?

edit retag flag offensive close merge delete


On my single node grizzly installation (a basic devstack setup), a disabled tenant is able to spawn instances (using existing token of a user belonging to that tenant). Can the operations that can be performed by a disabled tenant be configured (policy or elsewhere) ?

unmesh-gurjar gravatar imageunmesh-gurjar ( 2013-04-30 05:56:14 -0500 )edit

Seems like a bug. What about firing a bug report in launchpad?

rerngvit gravatar imagererngvit ( 2013-05-08 07:11:07 -0500 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2013-05-30 05:14:17 -0500

fifieldt gravatar image


As noted by one of the commenters, this activity seems like it is worthy of a bug report so it can be investigated by the developers.

This is a bug that likely spans several OpenStack projects, so there is a slight question of where to file it, but I would probably start with filing it in the OpenStack Identity Service project tracker (

In addition, once you have filed the bug, I believe this topic should be discussed on the development mailing list ( so a call to arms can be issued across all the projects to fix this - or at least determine what's going on :)

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2013-04-25 03:11:47 -0500

Seen: 445 times

Last updated: May 30 '13