<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Adam,<div><br></div><div>It's a valid debate....the thing I would add is that we should make the way group roles are handled consistently with whatever we do for inherited roles.  Group roles are a kind of inheritance (i.e. because I am a member of Group X, I inherit all the role assignments that Group X has.....we just don't call it "inheritance").  This is, of course, done at token creation time today....and will admit that I have just started the implementation of domain inherited roles using the same approach.</div><div><br></div><div>It seems to me that an efficient DB backend (particularly, when we move to a single assignments table in IceHouse) would be able to return all the domain inherited roles in one query (in fact you could have a query that got both inherited and non-inherited roles in one go I would think) - so not sure if we are adding too much to the load of token generation.  Taking the alternative approach of actually creating the assignment records at assignment time, I worry a bit about the duplication of state (i.e. we must store both the inherited assignment as well as the actual generated assignment records)....more scope for getting out of sync etc.</div><div><br></div><div>So right now I still favour the "at token generation time" approach.</div><div><br></div><div>Henry</div><div><br></div><div><br></div><div><br><div><div>On 28 Jun 2013, at 17:13, Adam Young wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Since I will be gone next week, and I
      know you want to move on with this, just wanted to confirm that I
      am OK with Henry's approach.<br>
      <br>
      I would like to suggest that we contemplate doing to inheritance
      mechanism at assignment time as opposed to token creation time as
      an optimization.  What would this mean?<br>
      <br>
      Say a domain role-assignement implies a project role assignment. 
      When a new project is created, we generate the role-assignments
      for the users that have domain entries explicitly at this point. 
      <br>
      <br>
      The objection I assume would be along the lines of "how are you
      sure you are going to get it right" and "that is going to generate
      a lot more entries in the database" which are both valid
      concerns.  However, token creation is far, far more common than
      changes to role assigments, and we should focus on optimizing for
      this use case.  In addition, it will remove the need for
      "effective" role assignments.<br>
      <br>
      One concern would be with "if we drop the inheritance
      relationship, what do we do with all those people that have that
      role already." We would have the choice of removing the
      role-assignments then, or of leaving them in place, and having to
      manually remove them.  We would have no means to distinguish
      between explicit and implicit role assignments.  I could entertain
      arguments on either approach, or even an additional parameter
      specifying what to do upon removal of the domain level assignment.<br>
      <br>
      <br>
      I don't see this as "make-or-break" but rather an implementation
      detail worth considering now.<br>
      <br>
      This would be consistent with the token revocation approach, where
      we make the effort to revoke all tokens at the time of the event.
      <br>
      <br>
      <br>
      <br>
      On 06/13/2013 09:49 AM, Henry Nash wrote:<br>
    </div>
    <blockquote cite="mid:D5E50DE7-B02A-4D9B-83B2-E6150931426B@linux.vnet.ibm.com" type="cite">Thanks Guang  - I have added responses, as well as
      tried to articulate the conceptual differences that actually
      underpin all these approaches.  This is in the intro in the
      etherpad, but reproduced below:
      <div><br>
      </div>
      <div>
        <div id="magicdomid553" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">Before looking at
            the possible solutions, it is worth pointing out that the
            differences in the various options boil down to how we
            approach two conceptual issues:</span></div>
        <div id="magicdomid555" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><br style="margin: 0px; padding: 0px; ">
        </div>
        <div id="magicdomid1191" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">1) How should we
            specify an assignment that applies to more than one entity? 
            There are two conceptual approaches:</span></div>
        <div id="magicdomid1190" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">- Use Inheritance,
            based on some grouping, hopefully one that already exists
            (e.g. use the fact that all projects are owned by a domain)</span></div>
        <div id="magicdomid888" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">- Use a logical
            expression (e.g. "apply to "*" )</span></div>
        <div id="magicdomid1129" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">The differences in
            these two concepts gets amplified if we want to be able, in
            the future, to further segregate role assignmnets based on
            some other subset (e.g. either hierachy of domains, or
            'apply to domains matching the string "army*" )</span></div>
        <div id="magicdomid1131" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><br style="margin: 0px; padding: 0px; ">
        </div>
        <div id="magicdomid1251" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">2) Should you
            specify the "scope" of the assignment separately from the
            assignment?</span></div>
        <div id="magicdomid1720" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">- Keeping them
            separate is considered good practice by our experts in this
            field, and this can be done by either storing the scope in
            another entity (e.g. the role def) or separatly in the
            assignment call.  </span></div>
        <div id="magicdomid1723" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">- If you don't keep
            them separate, then obviously it is all lumped into the
            assignment call.</span></div>
        <div id="magicdomid1624" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><br style="margin: 0px; padding: 0px; ">
        </div>
        <div id="magicdomid1719" class="ace-line" style="margin: 0px;
          padding: 0px 1px 0px 0px; color: rgb(0, 0, 0); font-family:
          Arial, sans-serif; font-size: 12px; font-style: normal;
          font-variant: normal; font-weight: normal; letter-spacing:
          normal; line-height: 16px; orphans: 2; text-align:
          -webkit-auto; text-indent: 0px; text-transform: none;
          white-space: normal; widows: 2; word-spacing: 0px;
          -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
          0px; "><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">The  proposed
            solutions only differ  fundamentally in how the approach
            these concepts (with consequences in the use cases below),
            the rest is just semantics.</span></div>
        <div><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); "><br>
          </span></div>
        <div><span class="author-a-gz68zyz85zz75zbaz122zrz88z8z87zz82z4z68zp" style="margin: 0px; padding: 1px 0px; cursor: auto;
            background-color: rgb(169, 217, 121); ">Henry</span></div>
        <div>
          <div>On 12 Jun 2013, at 22:46, Yee, Guang wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div>Added my comments in the etherpad.<br>
              <br>
              ----<br>
              <br>
              I really think role assignment merits its own CRUD. Since
              there's a new API<br>
              to get the role assignments.<br>
              <br>
              GET /role_assignments<br>
              <br>
              why not just have the complete API set to facilitate role
              assignments? That<br>
              way, we have one unified API for role<br>
              assignment, as oppose to multiple APIs as exist today.<br>
              <br>
              To get a role assignment:<br>
              <br>
              GET /role-assignments/{role_assignment_id}<br>
              <br>
              To remove a role assignment:<br>
              <br>
              DELETE /role-assignments/{role_assignment_id}<br>
              <br>
              To create a role assignment:<br>
              <br>
              POST /role_assignments<br>
              <br>
              {"role_assignment": {<br>
                 "user" {<br>
                     "id": user_id<br>
                 },<br>
                 "role": {<br>
                     "id": role_id<br>
                 },<br>
                 "scope": {<br>
                     "domain": {<br>
                         "id": domain_id<br>
                     },<br>
                     "project": {<br>
                         "id": project_id<br>
                     }<br>
                 }<br>
              }<br>
              <br>
              Note: "user" and "scope" is similar to the data structure
              in auth APIs. i.e.<br>
              can be either "id" or "name" + "domain".<br>
              If assignment is for a group, just have "group" in there
              instead of "user".<br>
              For example,<br>
              <br>
              {"role_assignment": {<br>
                 "group" {<br>
                     "id": group_id<br>
                 },<br>
                 "role": {<br>
                     "id": role_id<br>
                 },<br>
                 "scope": {<br>
                     "domain": {<br>
                         "id": domain_id<br>
                     },<br>
                     "project": {<br>
                         "id": project_id<br>
                     }<br>
                 }<br>
              }<br>
              <br>
              Upon successful creation, a assignment_ref is returned. <br>
              <br>
              {"role-assignment": {<br>
                 "id": role_assignment_id<br>
                 "user": {<br>
                     "id": user_id<br>
                 },<br>
                 "role": {<br>
                     "id": role_id<br>
                 },<br>
                 "scope": {<br>
                     "domain": {<br>
                         "id": domain_id<br>
                     },<br>
                     "project": {<br>
                         "id": project_id<br>
                     }<br>
                 }<br>
                 "links": {<br>
                     "self":<br>
              "<a moz-do-not-send="true" href="http://localhost:35357/v3/role-assignments/%7Brole_assignment_id%7D">http://localhost:35357/v3/role-assignments/{role_assignment_id}</a>"<br>
                 }<br>
              }<br>
              <br>
              "scope" is basically the combination and permutation of
              domains and<br>
              projects. "domain_id" or "project_id" can be "*" to denote
              all.<br>
              <br>
              Role assignment is really about assigning a given [role]
              to a given [user or<br>
              group] <br>
              for [a given project | a given domain | all projects
              within a given domain |<br>
              all projects in all domains | all domains].<br>
              <br>
              To assign a given role to a given user or group for [a
              given project]<br>
              <br>
              "scope": {<br>
                 "project": {<br>
                     "id": project_id<br>
                 }<br>
              }<br>
              <br>
              To assign a given role to a given user or group for [all
              the projects in a<br>
              given domain]<br>
              <br>
              "scope": {<br>
                 "domain": {<br>
                     "id": domain_id<br>
                 },<br>
                 "project": {<br>
                     "id": "*"<br>
                 }<br>
              }<br>
              <br>
              To assign a given role to a given user or group for [a
              given domain]<br>
              <br>
              "scope": {<br>
                 "domain": {<br>
                     "id": domain_id<br>
                 }<br>
              }<br>
              <br>
              To assign a given role to a given user or group for [all
              the projects in all<br>
              domains]<br>
              <br>
              "scope": {<br>
                 "domain": {<br>
                     "id": "*"<br>
                 },<br>
                 "project": {<br>
                     "id": "*"<br>
                 }<br>
              }<br>
              <br>
              To assign a given role to a given user or group for [all
              domains]<br>
              <br>
              "scope": {<br>
                 "domain": {<br>
                     "id": "*"<br>
                 }<br>
              }<br>
              <br>
              <br>
              The advantages of role_assignments CRUD are:<br>
              <br>
              1) simplicity (one API for role assignment, instead of
              multiple)<br>
              2) extensible (similiar to the auth API design). Say we
              need an assignment<br>
              at the federated level, we can simply add a new scope.<br>
              3) consistency (with the auth APIs)<br>
              4) RESTful (no need to worry about * in the path)<br>
              <br>
              <br>
              <br>
              Guang<br>
              <br>
              -----Original Message-----<br>
              From: Tiwari, Arvind <br>
              Sent: Wednesday, June 12, 2013 9:29 AM<br>
              To: Henry Nash<br>
              Cc: OpenStack Development Mailing List<br>
              Subject: Re: [openstack-dev] [keystone] More on inherited
              domain roles<br>
              <br>
              Hi Henry,<br>
              <br>
              Thanks for looking in to my comments, I was trying to
              raise #3 from your<br>
              list.  Any ways lets discuss this topic on etherpad from
              here onwards.<br>
              <br>
              Thanks,<br>
              Arvind<br>
              ________________________________________<br>
              From: Henry Nash [<a moz-do-not-send="true" href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>]<br>
              Sent: Wednesday, June 12, 2013 10:58 AM<br>
              To: Tiwari, Arvind<br>
              Cc: OpenStack Development Mailing List<br>
              Subject: Re: [openstack-dev] [keystone] More on inherited
              domain roles<br>
              <br>
              Hi<br>
              <br>
              So what you have described is correct, in terms of needing
              multiple roles IF<br>
              you want one role that only goes to projects and one that
              doesn't (e.g.<br>
              maybe goes to just domains). Role explosion was the issue
              raised against<br>
              using the role def to hold inheritance behaviour, when it
              was first<br>
              discussed.  However, I'd make the following comments:<br>
              <br>
              1) Most services don't need to be concerned about domains,
              just projects -<br>
              in fact, today, only keystone understands domains.  Hence
              there really won't<br>
              be a role explosion  in terms "Number of Services" x
              "Multiple roles due to<br>
              inheritance to projects or domains"<br>
              2) In addition, I can imagine than often a cloud provider
              will create  roles<br>
              that are project related separate from those that are
              domain related - they<br>
              tend to be different people doing those roles (e.g.
              user_group_admin vs<br>
              VM_admin etc.), so again, I think there won't be much of
              any additional role<br>
              explosion due to the inheritance rules between these roles<br>
              3) What there might be, is some role explosions between
              roles that go to all<br>
              domains vs roles that go to individual domains - for that,
              you will need<br>
              multiple roles.<br>
              4) For correctness (since we spend 40 mins on IRC on this
              :-) ), the<br>
              "inherited to:" field you use wasn't one of the discussed
              options - I agree<br>
              this is not the email to discuss that, but I don't want
              anyone thinking that<br>
              the structure below was one we looked at.<br>
              <br>
              For all:  The options being discussed are continuing on an
              etherpad, see:<br>
              <a moz-do-not-send="true" href="https://etherpad.openstack.org/keystone-role-inheritance">https://etherpad.openstack.org/keystone-role-inheritance</a>.
               This contains all<br>
              the various options being considered, including links to
              the previous ones<br>
              we looked at (e.g. not using the role def)<br>
              <br>
              Henry<br>
              On 11 Jun 2013, at 21:18, Tiwari, Arvind wrote:<br>
              <br>
              Hi All,<br>
              <br>
              Role inheritance is very cool feature and we need this in
              product, but<br>
              letting RoleDef to drive the inheritance behavior seem
              wrong to me as it<br>
              will cause roleDef explosion and complex policy for
              services to support.<br>
              <br>
              Let's assume a requirement<br>
              <br>
              1.       Cloud admin should have XYZ capability on all the
              projects, all<br>
              domains for Sev1. (Global inheritance)<br>
              2.       Domain admin should have XYZ capability only on
              the projects in<br>
              specific domain for Sev1. (inheritance scoped to a domain)<br>
              <br>
              With the current approach (having inherited to in roleDef)
              we have to have<br>
              following two roleDefs to support the requirement and
              hence you have to<br>
              adjust the policy around these two roleDefs but end result
              is XYZ<br>
              capability.<br>
              {<br>
                 "role": {<br>
                     "id": "---id---",<br>
                     "inheritedTo": "domain=all and project=all", (This
              means, holder of<br>
              this role has XYZ capability in all projects in all
              domains) (Lets not worry<br>
              about the how we implement it enum / Boolean flag)<br>
                     "links": {<br>
                         "self": "<a moz-do-not-send="true" href="http://identity:35357/v3/roles/76e72a">http://identity:35357/v3/roles/76e72a</a>"<br>
                     },<br>
                     "name": "XYZ-Role-4-cloud-admin"<br>
                 }<br>
              }<br>
              <br>
              {<br>
                 "role": {<br>
                     "id": "---id---",<br>
                     "inheritedTo": "project=all", (This means, holder
              of this role has<br>
              XYZ capability in all projects in specific domain)<br>
                     "links": {<br>
                         "self": "<a moz-do-not-send="true" href="http://identity:35357/v3/roles/76e72a">http://identity:35357/v3/roles/76e72a</a>"<br>
                     },<br>
                     "name": " XYZ-Role-4-domain-admin "<br>
                 }<br>
              }<br>
              <br>
              Think about growing number of service and above mentioned
              requirement, we<br>
              will end up with so many  roleDefs which will have
              duplicate capability and<br>
              hence redundant info to maintain in policy. At the same
              time this solution<br>
              does not address separation of concerns, we are
              unnecessary overloading the<br>
              roleDefs to impose role inheritance behavior which is not
              its concern. The<br>
              above mentioned requirement can be easily achievable by
              single roleDef (may<br>
              be XYZ-role-Svc1) if we remove inheritedTo concern from
              roleDef and place it<br>
              some ware else, role assignment is the right place to
              address this concern,<br>
              how that we need to figure out.<br>
              <br>
              Let me know if the issue I mentioned looks legitimate.<br>
              <br>
              <br>
              Thanks,<br>
              Arvind<br>
              <br>
              From: Henry Nash [<a class="moz-txt-link-freetext" href="mailto:henryn@linux.vnet.ibm.com">mailto:henryn@linux.vnet.ibm.com</a>]<br>
              Sent: Monday, June 10, 2013 4:30 PM<br>
              To: OpenStack Development Mailing List<br>
              Subject: [openstack-dev] [keystone] More on inherited
              domain roles<br>
              <br>
              Hi<br>
              <br>
              So I ave submitted two new api reviews around this:<br>
              <br>
              1) Defining inherited roles - this is now done on the role
              def itself, as<br>
              suggested by David. See: <a moz-do-not-send="true" href="https://review.openstack.org/#/c/29781/12">https://review.openstack.org/#/c/29781/12</a><br>
              2) The two un-implmented user/role apis have been replaces
              with a more<br>
              flexible way of listing role-assignments.<br>
              See:<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/32394/2">https://review.openstack.org/#/c/32394/2</a><br>
              <br>
              I'd like to push to get this nailed asap, so we can have a
               shot at getting<br>
              the code in!<br>
              <br>
              Both of these extensions are designed to give us the
              option to to expand<br>
              this support for inheritance to all domains in the future
              if we chose.<br>
              <br>
              Henry<br>
              <br>
              <br>
              _______________________________________________<br>
              OpenStack-dev mailing list<br>
              <a moz-do-not-send="true" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>