<div dir="ltr">Hi Henry,<div><br></div><div>As you said before, this Reseller implementation is not simple, so this plan sounds reasonable for me.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 18, 2015 at 9:53 AM Henry Nash <<a href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi<div><br></div><div>During our IRC meeting this week, we decided we needed a recap of this plan, so here goes:</div><div><br></div><div><b>Phase 0 (already merged in Liberty):</b></div><div><br></div><div>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).</div><div><br></div><div><b>Phase 1 (all code up for review for Mitaka):</b></div><div><br></div><div>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.</div></div></blockquote><div>++ For this phase does not provide support for reseller, we need the phase 2 anyway. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Phase 1 is covered by the two approved specs: HMT (<a href="https://review.openstack.org/#/c/139824" target="_blank">https://review.openstack.org/#/c/139824</a>, this actually coves Phase 1 and 2) and is_domain token (<a href="https://review.openstack.org/#/c/193543/" target="_blank">https://review.openstack.org/#/c/193543/</a>)</div><div><br></div><div><div><b>Phase 2 (earlier versions of code were proposed for Liberty, need fixing up for Mitaka):</b></div><div><br></div><div>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 (<a href="http://lists.openstack.org/pipermail/openstack-dev/2015-October/078063.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-October/078063.html</a>), 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:</div><div><br></div><div>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, <a href="https://review.openstack.org/#/c/139824" target="_blank">https://review.openstack.org/#/c/139824</a>). Given that we would already have Phase 1 in place, the actual changes in Phase 2 would be as follows:</div></div><div><br></div><div>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).</div><div>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.</div><div>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.</div><div>d) All domain names (i.e. project names for projects acting as domains) must still be unique (otherwise we break our current auth model)</div><div><br></div><div>Comments on the issues that people have raised with Phase 2:</div><div><br></div><div>i) It’s too complex!</div><div>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.</div><div><br></div><div>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.</div><div>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.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>iii) What’s this about name clashing?</div><div>Ok, so there are two different scenarios here:</div><div>> 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.</div><div>> 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:</div><div> >> 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.</div><div>>> 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.</div><div>I’d support putting one of these additional restrictions in place - which we could always then consider loosening in subsequent releases.</div></div></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I’d like to get confirmation that we are OK to proceed along this original plan that we agreed during the Liberty cycle.</div><div><br></div><div>Henry</div><div><br></div><div><br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>