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 <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
