Hierarchical Projects and Inherited Role Assignments
Summary
=======
As of Kilo-1 release, keystone introduced a hierarchical structuration of
projects. Aiming to improve user experience on this new organization, it is
proposed to support it on horizon, the OpenStack dashboard.
Motivation
==========
Real-world organizational structures tend to be hierarchical. As an example,
suppose an organization that have tens of departments hierarchically organized,
in which each sub department is a part of the parent department.
The best representation of this departmental hierarchy is in the form of a
tree, as they originally are structured, and not in a flat representation.
Aiming to enable such representation on OpenStack, the concept of hierarchical
projects was introduced by keystone, the OpenStack Identity service.
In order to improve user experience on hierarchical projects, it is proposed to
add support for such concept on horizon, the OpenStack dashboard.
Description
===========
The following features will be added on horizon:
a. Addition of Parent Project
Addition of parent project information when creating a project, allowing users
to build their project hierarchy. In addition, this information will be shown
when listing projects in admin mode.
b. Show Project Hierarchy
Show project hierarchy on projects panel, enabling users to view the existing
project hierarchy.
c. Use Project in Hierarchy
List project hierarchy on project selector dropdown, making it possible for
users to select the project in the hierarchy they want to use.
d. CRUD of Inherited Role Assignments
Inherited role assignments are specially useful in the cases where a role
assignment should be applied to all projects under a given root domain or
project, because instead of creating a role assignment for each project under
that root, a single inherited one on the root project provides the same effect.
This feature will enable the CRUD of inherited role assignments on horizon.
UX
==
Wireframes, Mocks, Videos and UI Markup
-------
For the features that need to represent projects structure, it is proposed to
represent them in the form of a tree, as the project hierarchy is.
An alternative would be to represent them as horizon currently does, but
inserting the parent names for each project, separated by a character, such as
a slash. See [1] as an example for feature c. Use Project in Hierarchy.
a. Addition of Parent Project
Addition of a drop-down list on Create Project screen [2]. The default will be
the project the user is currently using. This list will contain all the
projects the user has access to, organized hierarchicaly.
When editing the project, the parent cannot be updated [3], since it is a
constraint adopted by keystone because it would be too complex to edit the
hierarchy due to token revocations and quota checkings.
When listing projects in admin mode, a column should be added to show the
parent project name.
b. Show Project Hierarchy
The projects will be organized in an expandable tree view, honoring the project
hierarchy, according to the projects the user has access to, as shown in [4].
c. Use Project in Hierarchy
The select project drop-down list will be similar to the one proposed to be
added on the Create Project screen for selecting the parent project.
d. CRUD of Inherited Role Assignments
On the project member roles management screen, inherited role assignments will
be represented by a globe icon next to the role assignment. Regarding deletion,
there will be a trash icon next to the role assignment [5].
To add a new role assignment to a user, a plus button will be added. When
clicked, it will open a new screen showing available roles, each one having an
option to mark it as inherited.
Testing
=======
The only non-obvious effect that needs to be considered in tests is that
inherited role assignments are not applied to the project they belong to, but
to its subprojects.
Outside Dependencies
=======
Features with Project Hierarchy
-------
For features a, b and c, that involve retrieval of the project hierarchy in
which the user has access to, the support on keystone service is already merged
and will be stable for Kilo release.
In addition, it will be required two ongoing patches on python-
1. “Implements subtree_as_ids and parents_as_ids” [6], which enable the query
of projects IDs up and down the hierarchy as a structured dictionary.
2. “Hierarchical multitenancy basic calls” [7], which enable the query of list
of projects up and down the hierarchy.
In order to retrieve the project hierarchy, horizon will use those two calls,
where the first one will give the full hierarchy structure in the form of ids,
and the second one will provide detailed information about the projects in the
hierarchy the user has access to.
CRUD of Inherited Role Assignments Feature
-------
Inherited role assignments on domains are already supported on keystone as an
extension since Havana release. Inherited project role assignments were
introduced on Keystone in Kilo-1, along with the hierarchical projects concept.
This feature will be a base API functionality in Kilo release.
An ongoing patch on python-
domain calls on keystoneclient v3 [8].
Requirements Update Required
=======
Update python-
merged and a new version of it is released.
Doc Impact
==========
Horizon documentation will be updated in order to expose to the user the new
features that will be introduced.
References
==========
[1] https:/
[2] http://
[3] http://
[4] http://
[5] https:/
[6] https:/
[7] https:/
[8] https:/
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Samuel de Medeiros Queiroz
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Richard Jones
