Open Stack

Hi

One of the things the keystone team was planning to merge ahead of milestone-3 of Mitaka, was “projects acting as a domain”. Up until now, domains in keystone have been stored totally separately from projects, even though all projects must be owned by a domain (even tenants created via the keystone v2 APIs will be owned by a domain, in this case the ‘default’ domain). All projects in a project hierarchy are always owned by the same domain. Keystone supports a number of duplicate concepts (e.g. domain assignments, domain tokens) similar to their project equivalents.

The idea of  “projects acting as a domain” is:

- A domain is actually represented as a super-top-level project (with an attribute, “is_domain" set to True), and all previous top level projects in the domain specify this special project as their parent in their parent_id attribute. A project with is_domain=True is said to be a “project acing as a domain”. Such projects can not have parents - i.e. they are at the top of the tree.
- The project_id of a project acting as a domain is the equivalent of the domain_id.
- The existing domain APIs are still supported, but behind the scenes actually reference the “project acing as a domain”, although in the long run may be deprecated. On migration to Mitaka, the entries of the domain table are moved to be projects acting as domains in the project table
- The project api can now be used to create/update/delete a project acting as a domain (by setting is_domain=True) just like a regular project - and do the equivalent of the domain CRUD APIs
- Although domain scoped tokens are still supported, you can get a project scoped token to the project acting as a domain (and the is_domain attribute will be part of the token), so you can write policy rules that can solely respond to project tokens. We can eventually deprecate domain tokens, if we chose.
- Domain assignments (which will still be supported) really just become project assignments placed on the project acting as a domain.
- In terms of the impact on the results of list projects:
— There is no change to listing projects within a domain (since you don’t see “the domain” is such a listing today)
— A filter is being added to the list projects API to allow filtering by the is_domain attribute - with a default of is_domain=False (i.e. so unless you ask for them when listing all projects, you won’t see the projects acting as a domain). Hence again, by default, no change to the collection returned today.

The above proposed changes have been integrated into the latest version of the Identity API spec: https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html

I’ve got a couple of questions about the impact of the above:

1) I already know that if we do exactly as described above, the cinder gets confused with how it does quotas today - since suddenly there is a new parent to what it thought was a top level project (and the permission rules it encodes requires the caller to be cloud admin, or admin of the root project of a hierarchy).
2) I’m not sure of the state of nova quotas - and whether it would suffer a similar problem?
3) Will Horizon get confused by this at all?

Depending on the answers to the above, we can go in a couple of directions. The cinder issues looks easy to fix (having had a quick look at the code) - and if that was the only issue, then that may be fine. If we think there may be problems in multiple services, we could, for Mitaka, still create the projects acting as domains, but not set the parent_id of the current top level projects to point at the new project acting as a domain - that way those projects acting as domains remain isolated from the hierarchy for now (and essentially invisible to any calling service). Then as part of Newton we can provide patches to those services that need changing, and then wire up the projects acting as a domain to their children.

Interested in feedback to the questions above.

Henry