Open Stack

Sooo to follow up from the discussion last night partly with Lance and
Adam, I'm still not exactly sure what difference, if any, there is
between a domain scoped role assignment, and a project scoped role
assignment. And... It appears stuff breaks when you used both, or either
actually (more on that further down).

My problem/confusion was why the following exists or is possible:
http://paste.openstack.org/show/695978/
The amusing part, I now can't remove the above role assignments. They
throw a 500:
http://paste.openstack.org/show/696013/
The error itself being:
http://paste.openstack.org/show/695994/

Then lets look at just project scope:
http://paste.openstack.org/show/696007/
I can't seem to do 'include_names' on the project scoped role
assignment, but effective works since it doesn't include the project. I
have a feeling the error is because keystone isn't including projects
with is_domain when doing the names mapping.

So... going a little further, does domain scope still act like project
scope in regards to effective roles:
http://paste.openstack.org/show/695992/
The answer is yes. But again, this is domain scope, not project scope
which still results in project scope down the tree. Although here
'include_names' works, this time because keystone internally is directly
checking for is_domain I assume.

Also worth mentioning that the following works (and maybe shouldn't?):
http://paste.openstack.org/show/696006/
Alice has a role on a 'project' that isn't part of her domain. I can't
add her to a project that isn't in her domain... but I can add her to
another domain? That surely isn't expected behavior...


Weird broken stuff aside, I'm still not seeing a difference between
domain/project role assignment scope on a project that is a domain. Is
there a difference that I'm missing, and where is such a difference used?

Looking at the blog post Adam linked
(https://adam.younglogic.com/2018/02/openstack-hmt-cloudforms/), he
isn't  really making use of domain scope, just project scope on a
domain, and inheritance down the tree, which is indeed a valid and
useful case, but again, not domain scope assignment. Although domain
scope on the same project would probably (as we see above) achieve the
same result.

Then looking at the policy he linked:
http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n52
"identity:list_projects": "rule:cloud_admin or
rule:admin_and_matching_domain_id",
    - "cloud_admin": "role:admin and (is_admin_project:True or
domain_id:admin_domain_id)",
    - "admin_and_matching_domain_id": "rule:admin_required and
domain_id:%(domain_id)s",
        -  "admin_required": "role:admin",

I can't exactly see how it also uses domain scope. It still seems to be
project scope focused.

So my question then is why on the role assignment object do we
distinguish between a domain/project when it comes to scope when a
domain IS a project, and clearly things break when you set both.

Can we make it so the following works (a hypothetical example):
http://paste.openstack.org/show/696010/
At which point the whole idea of 'domain' scope on a role assignment
goes away since and is exactly the same thing as project scope, and also
the potential database 500 issues goes away since... there isn't more
than 1 row. We can then start phasing out the domain scope stuff and
hiding it away unless someone is explicitly still looking for it.

Because in reality, right now I think we only have project scope, and
system scope. Domain scope == project scope and we should probably make
that clear because obviously the code base is confused on that matter. :P