This spec proposes the addition of config options and internal plumbing required for a cinder-internal tenant. This tenant can then be used by Cinder as the owner of internal objects that we don’t really want owned by any normal users.
There are several use cases for ‘internal’ cinder objects where we would like to prevent a normal user from seeing them. The approach that seems to have the most backing is to a special tenant that cinder can use for owning these internal volumes/snapshots/etc.
There are a few different use cases for the internal tenant. The generic use case is for any volume or snapshot object in Cinder that we do not want exposed to normal users, but would like to keep track of and have treated as normal volumes and snapshots.
There are a few features which would be able to take advantage of this:
I think initially the easiest way to make this work is to add new config options that take in the credentials for the tenant. This would require an admin to create and configure the tenant manually and then set the values in cinder.conf. These config options will be:
These config options will default to ‘None’. For some features like the image cache this isn’t such a big deal. If the credentials are none, and the tenant is unavailable the cache just won’t actually create cache objects and things fall back to the original functionality. It will however be more difficult for features like migration or backups where they may not be able to fall back nicely to a behavior that does not need the credentials.
Things like quota and other permissions would be managed by an admin only, cinder will not modify things automatically. In the future it would be possible to have default values for the config options, and allow cinder to mange the tenant. That functionality will be out of scope for this initial implementation.
For the initial change I don’t think we should keep any of this info in the cinder db. Everything comes from the config file and is re-checked at startup.
Any usage of the tenants objects should assume they could be deleted or cleaned up at any time, I don’t think this is any different than the case today where a user could delete a second volume halfway through migration though. So this is not a regression. The idea behind this being that as an admin you could periodically clean these objects up if they start to accumulate, but you wouldn’t really need to worry about which ones are ‘safe’.
Another way to approach this problem is to add ‘hidden’ flags to volumes and snapshots. The biggest downside of this is that all API’s need to then know about this and start filtering, and potentially clients and commands need new ‘–hidden’ or ‘–show-all’ kind of flags. In addition these hidden volumes may either take quota from a real user or not be accounted for at all.
Care will need to be taken to ensure the tenant credentials are not exposed to anyone other than cloud administrators and that users cannot create volumes or other objects as the internal tenant.
This change by itself shouldn’t have any end user impact. Things built on top of it may change what a user sees while using commands like migrate.
New config options and setup steps when configuring cinder.
Additional documentation to read.
New internal API’s to use to create objects as the internal tenant.
Unit tests for the utility functions.
This change by itself won’t require tempest test changes or additions, but features utilizing it will.