Cloud-vps object storage via swift and S3 would be vastly more useful if individual tools could have secure access to it. Because toolforge is a single keystone tenant, right now the default access policy is that /everything/ in toolforge will be accessed via the same credentials which is not very useful.
There are several approaches we could take.
* On-demand bespoke keystone project creation
** Users request a cloud-vps project with limited quotas that only permit object storage (no VMs, etc since that's not what they need.)
*** **Pro**: requires no development, we can start doing this today. Supports UI access via horizon, all existing keystone access patterns
*** **Con**: not a great approach if we have more than a dozen or so tools using this. Can't be used to integrate with build service or other toolforge services since it's not always present.
*** **Con**: tedious user experience
*** **Con**: tedious maintenance for users (different UI, different tooling)
*** **Con**: no self-service, requires us to create the project and keep it in sync with user permissions
* Automatic creation of per-tool keystone project (projects in database)
** An agent creates a specially-prefixed keystone project for each existing tool account (in a database-backed domain), creates storage-specific app credentials, injects them into the toolforge account (as with replica.cnf)
*** **Pro**: Keystone projects could be re-used for trove or other non-compute openstack resources.
*** **Con**: Database-stored keystone projects should work (they're the standard use case) but they'll introduce a bunch of new pathways in our deployment.
*** **Con**: If we want to provide Horizon access we need passwords as well as app credentials, will need to figure out a 'forgot/create password' Horizon workflow that doesn't interfere with our existing password model for 'normal' cloud-vps projects.
*** **Con**: tedious user experience
*** **Con**: tedious maintenance for users (different UI, different tooling)
*** **Mystery**: Are there any scaling concerns with having thousands of projects rather than dozens?
*** **Note**: we can do this only on-demand, instead of pre-creating them, that alleviates considerably the amount of projects (most tools won't need it)
* On-demand creation of per-tool keystone project (projects in database), exposed as an toolforge API (have a service that allows creating projects + s3 storage in cloudVPS, then expose it as a Toolforge API)
** Same as before, but users only interact with it through a toolforge API, and projects are created only on demand
*** **Pro**: Keystone projects could be re-used for trove or other non-compute openstack resources.
*** **Pro**: unified user experience, users don't have to change tools/UIs/environments to managed toolforge resources
*** **Pro**: easy maintenance for users (self-sevice), they create the resources when they need without admin interaction
*** **Con**: Database-stored keystone projects should work (they're the standard use case) but they'll introduce a bunch of new pathways in our deployment.
*** **Mystery**: Are there any scaling concerns with having thousands of projects rather than dozens?
*** **Note**: we can do this only on-demand, instead of pre-creating them, that alleviates considerably the amount of projects (most tools won't need it)
* Automatic creation of per-tool keystone project (projects in ldap)
** Create a new ldap-backed keystone domain (via keystone config) that consumes our existing toolforge account records in ldap as tenant descriptions. An agent creates and injects application credentials for swift/s3 usage.
*** **Pro**: We wouldn't need an agent to worry about account creation or deletion, that happens for free as ldap records are created/deleted. We'd still probably need an agent for credential management.
*** **Pro**: Keystone projects could be re-used for trove or other non-compute openstack resources.
*** **Con**: If we want to provide Horizon access we need passwords as well as app credentials, will need to figure out a 'forgot/create password' Horizon workflow that doesn't interfere with our existing password model for 'normal' cloud-vps projects.
*** **Con**: tedious user experience
*** **Con**: tedious maintenance for users (different UI, different tooling)
*** **Mystery**: Are there any scaling concerns with having thousands of projects rather than dozens? I'm less worried about this with ldap but it could still crop up as a problem in places.
* Per-tool bucket creation and access
** An agent or privileged script creates a bucket/container for a given tool, creates *waves hands* bucket-specific credentials and provides them to the toolforge admin.
*** **Pro**: diy means we'd have total control over the user experience.
*** **Pro**: Smaller maintenance footprint as Keystone is unaware of this entirely, it's just us and the radosgw.
*** **Pro**: unified user experience, users don't have to change tools/UIs/environments to managed toolforge resources
*** **Pro**: easy maintenance for users (self-sevice), they create the resources when they need without admin interaction
*** **Con**: access via CLI only, no Horizon ever - this might not be a con
*** **Con**: doesn't help with Trove at all
*** **Mystery**: Is it possible/practical to make per-container credentials? Does radosgw support this at the same time as the existing keystone integration? (note to self, this is something to do with IAM policies)
* toolforge-specific radosgw server with one storage account per tool
** An agent or privileged script creates a rados account for each tool, injects credentials into tool account.
*** **Pro**: Each tool is a first-class member of object storage service, with access to the full feature set and arbitrarily many buckets or containers.
*** **Pro**: diy means we'd have total control over the user experience.
*** **Pro**: Smaller maintenance footprint as Keystone is unaware of this entirely, it's just us and the radosgw.
*** **Pro**: unified user experience, users don't have to change tools/UIs/environments to managed toolforge resources
*** **Pro**: easy maintenance for users (self-service), they create the resources when they need without admin interaction
*** **Con**: access via CLI only and API, no Horizon involvement
*** **Con**: doesn't help with Trove or other openstack services