Open Stack

Hello Everyone,

We have received a good amount of feedback from the operator. In ops meetup Berlin as well
as from KDDI (Japanese telco). I have summarized the feedback in etherpad[1]. From feedback,
it is clear that 'scope' enable will break heat so do NFV operators and even other operators are also
confused with the 'scope' concept. Most operators want legacy admin to work as it is (able 
to do everything in deployment).

We discussed this feedback in the policy popup meeting[2] and based on feedback and our
outstanding issue of 'scope enable break heat create_stack',  we decided to postpone the
`scope` implementation. That is the way forward to at least implement the project personas which
is asked by many operators. Basically the below direction:

* Finish delivering project personas
  This is to introduce the `member` and `reader` roles to operate things within their project.
  By default, any other project role like `foo` will not be allowed to do anything in
  the project.

* Postpone the `scope` implementation for later
  Some standalone services like Ironic can still have the `scope` implementation as
  long as it does not break any cross-service communication. Other services will make sure
  they work for project scope personas even with enforce_scope enabled. 

We are not saying 'scope' things are not good or we will never do it but at the same time, I am not sure
when we will do it in future. At least moving this giant goal to focus on the project personas first will
help us to deliver one good feature (project personas) for operators otherwise we are stuck.

Complete details about the reason to postpone the 'scope' implementation and projects persons
detail are proposed in community-wide goal, please review there.

- https://review.opendev.org/c/openstack/governance/+/847418

[1] https://etherpad.opendev.org/p/rbac-operator-feedback#L45
[2] https://etherpad.opendev.org/p/rbac-zed-ptg#L171