Open Stack

Hi Henry,

As you said before, this Reseller implementation is not simple, so this
plan sounds reasonable for me.

On Wed, Nov 18, 2015 at 9:53 AM Henry Nash <henryn at linux.vnet.ibm.com>
wrote:

> Hi
>
> During our IRC meeting this week, we decided we needed a recap of this
> plan, so here goes:
>
> *Phase 0 (already merged in Liberty):*
>
> We already support a hierarchy of projects (using the parent_id attribute
> of the project entity). All the projects in a tree must be in the same
> domain. Role assignment inheritance is supported down the tree (either by
> assigning the role to the domain and have it inherited by the whole tree,
> or by assigning to a node in the project tree and having that assignment
> inherited by the sub-tree below that node).
>
> *Phase 1 (all code up for review for Mitaka):*
>
> Keep the existing conceptual model for domains, but store them as projects
> with a new attribute (is_domain=True).  The domain API remains (but
> accesses the project table instead), but you can also use the project API
> to create a domain (by setting is_domain=True). The is_domain attribute is
> immutable - i.e. you can’t flip a project between being a regular project
> and one acting as a domain. Projects acting as a domain have no parent
> (they are always top level domains/projects). Domain tokens can be
> deprecated in place of a project token scoped to a project acting as a
> domain (the token is augmented with the is_domain attribute so a policy
> rule can distinguish between a token on a domain and a regular project).
> This phase does not provide any support for resellers.
>
++ For this phase does not provide support for reseller, we need the phase
2 anyway.

>
> Phase 1 is covered by the two approved specs: HMT (
> https://review.openstack.org/#/c/139824, this actually coves Phase 1 and
> 2) and is_domain token (https://review.openstack.org/#/c/193543/)
>
> *Phase 2 (earlier versions of code were proposed for Liberty, need fixing
> up for Mitaka):*
>
> At the summit we agreed to re-examine Phase 2 to see if we could perhaps
> use federation instead to cover this use case. As outlined in my email to
> the list (
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/078063.html),
> this does not provide the support required. Hence, as per that email, I am
> proposing we revert the original specification (with restrictions), which
> is as follows:
>
> Extended the concept of domains to allow a hierarchy of domains to support
> the reseller model (the requirements and specifications are in the same
> approved spec that covers Phase 1 above,
> https://review.openstack.org/#/c/139824). Given that we would already
> have Phase 1 in place, the actual changes in Phase 2 would be as follows:
>
> a) Since projects already have a parent_id attribute and domains are
> represented as projects with the is_domain attribute set to True, allow
> projects acting as domains to be nested (like regular projects).
> b) The parent of a project acting as a domain must either be another
> project acting as a domain or None (i.e. a root domain). A regular project
> cannot act as a parent for a project acting as a domain. In effect, we
> allow a hierarchy of domains at the top of “the tree” and all regular
> project trees hang off those higher level domains.
> c) Projects acting as domains cannot be the recipient of an inherited role
> assignment from their parent - i.e. we don’t inherit assignments between
> domains.
> d) All domain names (i.e. project names for projects acting as domains)
> must still be unique (otherwise we break our current auth model)
>
> Comments on the issues that people have raised with Phase 2:
>
> i) It’s too complex!
> Well, in terms of code changes, the majority of the changes are actually
> in Phase 0 and 1. We just use the underlying capabilities in Phase 2.
>
> ii) Our restriction of “all domain names must be unique” means that one
> reseller could “squat” on a domain name and prevent anyone else from having
> a domain of that name.
> This is absolutely true. In reality, however, reseller arrangements will
> be contractual, so if a cloud provider was really concerned about this,
> they could legislate against this in the contract with the reseller (e.g.
> "All the domains you create must be suffixed with your reseller name”). In
> addition, if we believe that federation will become the dominant auth
> model, then the physical name of the domain becomes less important.
>

> iii) What’s this about name clashing?
> Ok, so there are two different scenarios here:
> > Since, today, a project can have the same name as it’s domain, this
> means that when we convert to using projects acting as a domain, the same
> thing can be true (so this is really a consequence of Phase 1). Although we
> could, in theory, prevent this for any new domains being created, migrating
> over the existing domains could always create this situation. However, it
> doesn’t actually cause any issue to existing APIs, so I don’t think it’s
> anything to be concerned about.
> > In Phase 2, you could have the situation where a project acting as a
> domain has child projects some of which are regular and some of which are
> themselves acting as domains. In that case, you could create one regular
> project and a sibling project acting as a domain, both having the same name
> within the same parent (which will, by definition, always be another
> project acting as a domain). The currently proposed APIs prevent confusion,
> since we don’t allow you to list all child projects of a parent,
> irrespective of whether they are acting as a domain or not. When listing
> projects, is_domain defaults to False (so you just see regular projects,
> like you do today) or you can explicitly ask for projects that are acting
> as domains (within a parent) - but you can’t ask for both types. Note that
> we *could* prevent this version of name clashing from ever occurring, via
> one of two ways:
>  >> By adding a restriction on create/update that says a project’s name
> must be unique within its parent (irrespective of whether the project being
> created is acting as a domain or not).  Note, that you can’t get into this
> problem from migration (since there are no sub domains currently). The only
> consequence of this additional restriction is that it potentially makes the
> squatting problem listed above more of an issue - since creating a regular
> project inside a project acting as a domain would prevent the creation of a
> sibling project acting as a domain. In reality, in the reseller case,
> that’s probably not an issue, since again you can legislate against it, or
> simply choose a more strict hierarchy (i.e. not mixing the two types of
> project within one domain) to avoid it.
> >> By being even more restrictive and saying that children of a project
> acting as a domain can only be of one type (regular or other projects
> acting as a domain). This might be slightly over restrictive for some
> customers, but would make for very clean hierarchies.
> I’d support putting one of these additional restrictions in place - which
> we could always then consider loosening in subsequent releases.
>
If we choose this last option we may impact current deploys that already
have regular projects below a domain, since they will not be able do create
projects acting as a domain in the current domains.

>
> I’d like to get confirmation that we are OK to proceed along this original
> plan that we agreed during the Liberty cycle.
>
> 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/20151118/98537a40/attachment.html>