Open Stack

See inline response for horizon-related feedback.

Hope this helps.

-Lin

On Sat, Jan 30, 2016 at 7:02 PM, Henry Nash <henrynash9 at mac.com> wrote:

> 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.
>

Excellent. Some folks are working on making the domain scope token worked
on horizon to make the identity operations available in horizon when using
keystone V3 (since domain scoped token is required by the policy file to do
cloud admin stuff). With this change, horizon can re-use the same project
scoping mechanism.


> - 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?
>

Horizon doesn't support project hierarchy yet, so there's not a lot of
impact with the proposed change.

As long as the Domain API behavior is retained and the List Project API
keeps the old behavior, horizon should work just fine.

So horizon will continue to use the Domain API, and can switch to the new
API when the "project acting as domain" stabilized next release.


>
> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160201/63482084/attachment.html>