RFC: Managing quotas

[Be-El]

One of the adapter's goals is managing project quotas; the resource definition in a perun project should be reflected by setting the corresponding quotas in openstack.

I've been thinking about this problem for time now, since we want to write a script to simplify project setup. And it turns out that this script is a little bit more involved than previously thought....

In an idea world I would create one account and make it domain admin of the de.NBI domain. This account can be used to create users, projects and manage quotas. This works, and this is how I want to setup the adapter.

But managing quotas does not work with this account for all types of quotas. It's fine for keystone quotas, but breaks for certain other quotas, notably cinder quotas. Their quota definition is managed by cinder/neutron itself; to set quotas you need to talk with the component's endpoint. This endpoint requires a project/tenant id:

# openstack endpoint list --service volumev3
+----------------------------------+-----------+--------------+--------------+---------+-----------+----------------------------------------------------------------------+
| ID                               | Region    | Service Name | Service Type | Enabled | Interface | URL                                                                  |
+----------------------------------+-----------+--------------+--------------+---------+-----------+----------------------------------------------------------------------+
| 36bb45416ffe48acbfbe8fc056100b08 | RegionOne | cinderv3     | volumev3     | True    | public    | https://cloud.computational.bio.uni-giessen.de:8776/v3/%(tenant_id)s |
| 6b55fb61e5ef431b9b26ca84d92c4299 | RegionOne | cinderv3     | volumev3     | True    | internal  | http://192.168.12.5:8776/v3/%(tenant_id)s                            |
| fa5fd05ed28842cb9f80dd2042757566 | RegionOne | cinderv3     | volumev3     | True    | admin     | http://192.168.12.5:8776/v3/%(tenant_id)s                            |
+----------------------------------+-----------+--------------+--------------+---------+-----------+----------------------------------------------------------------------+

Working as domain admin is defined by NOT specifying a project and thus getting a domain scoped keystone token. Without a project you cannot use the cinder endpoint....

I'm not sure about the best method to handle this problem. Using a second keystone instance with a project admin account probably does not work, since project admin A might not be able to modify porject B. cinder (and almost all other components except keystone) does not support the domain concept at all yet.

We are currently aiming at

• create a project via domain admin account
• make service account admin of the new project
• create new keystone session as project admin in the new project
• modify storage quotas
• remove service account membership

I haven't tested this yet, so I'm not sure whether it works. In the worst case we either have to change the policies for cinder (and maybe other components), which will open up a can of worms....or we have to use a cloud admin account. The later one would be the absolute last resort...

Any comments on this? How do you handle automatic quota setup at your site?

[jkrue]

As you mentioned a domain admin account can't be used to set quotas. For this reason we currently run the adapter with admin privileges. This might not the best solution, but is this really a big problem ? Since the adapter do not delete resources automatically this seems to be ok for me.

[Be-El]

It's a matter of security vs. effort. I prefer to use the least privileges necessary to perform a task, even if this means extra effort in the implementation. And storing cloud admin credentials for any automated task is kind of a no-go in my opinion.

I'm preparing a branch for the necessary fixes in the current master; extensions for quota support will be added after the initial quota implementation is complete.

[hexylena]

It's fine from Freiburg's side, @jkrue. We already store cloud admin credentials (on our management nodes) for automated tasks like syncing flavor lists. Given our threat model, it isn't a big concern to likewise provide the adapter with credentials.

Glad you have the time to put in the extra effort for the extra security @Be-El.

[Be-El]

Quota management as domain admin is no problem......except for the cinder quotas. You need to add the domain admin as project admin to each managed project; retrieving and setting quotas requires as new project scope authentication token.

If the current work at the quota implementation in branch feature/transfer-quotas is finished, I would start implementing a token cache and do the necessary changes to handle cinder quotas correctly.

The important question we need to answer before: Do we want to add the service account as project admin permanently to each project, or do we want to assign roles on the fly? How often does perun trigger the keystone adapter?

(Another alternative are nested projects.....currently evalutating)