prevent default tenant deletion

Maybe we could add a warning dialog to prevent users from falling in this situation. This should be fixed in the near future in https://blueprints.launchpad.net/horizon/+spec/tenant-deletion.

How do we detect or define what is a "default" project though?

I wonder if any of the UX folks would have thoughts on how to handle this?

Most installation guides suggest creating a default project called 'service' for the service users from Nova, Neutron, etc to use (e.g. http://docs.openstack.org/icehouse/install-guide/install/yum/content/keystone-users.html ). This is the kind of project/tenant we would want to prevent the accidental deletion of.

We could specifically look for projects named 'service' (and whatever else) but then this becomes very limited and will not work when deployers in other languages use translated names for their projects.

We could rely on a Keystone flag of some sorts, although it looks like this would require a change to Keystone because the project table does not have an 'extra' attribute (like e.g. users do).

We could add yet another setting to Horizon whereby a deployer could set a list of project that they believe should not be deletable. This may be the most flexible option.

...This is probably blueprint material.

And in the meantime there is of course the brute-force workaround of setting identity:delete_project to a non-existent role or a specific user. (I wonder if it'd be possible to write a policy for 'is_admin + not any of these tenants'? Either in policy.json itself ideally or using the customisation module possibly.)

Then there is the matter of the messaging. Do we want to prevent deletion at all, or help the user knows what they're about to do somehow (e.g. "If you delete this project you will lose functionality" or something like that...)

Actually there is bug 948644 that looks to address a very similar issue. The Keystone folks make a point that "specialness" can already be handled via using separate domains. I'm not sure if it's possible for Horizon to avail of this yet considering the current issues with using v3 and domains? (I'm thinking of bug 1294396)

I definitely like the idea of warning the user (letting them know exactly what they would be doing by deleting this project) and having them confirm deletion. But it does make me wonder what really happens if the user does delete this "default" project. Is it really just a project that is set up initially for them to kickstart their cloud environment? And if they delete it and set up a new project it will run the same? In this case, I'd say we allow them to delete the project with warning/confirmation. If this default project has deeper hooks into the system and deleting it would cause issues for future projects we should probably open a blueprint to discuss this further.

My thoughts,
Liz

Deleting the project causes authentication issues for the other services so it is pretty serious. (One needs to recreate the project and re-add the members to fix it.)

There's a number of workarounds that can be done today already (updating the identity policy (e.g. to disallow entirely or only allow a "superadmin" role of some sort to delete projects), creating a separate domain, using the customisation module to disallow deletion based on e.g. project name) so I'm not sure how much effort is worth spending on this.

Putting into wishlist based on Julie's input (workarounds exist, and a low value for the effort)

I think this patch solves the problem: https://review.openstack.org/#/c/142481/