keystone-manage bootstrap assumes user-project role assignment

Bug #1553224 reported by Matthew Edmonds on 2016-03-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)

Bug Description

keystone-manage bootstrap creates a role assignment for the specified user on the specified project. That is one way someone might want to do bootstrapping, but there are good reasons a user may need/prefer:

1) user-domain role assignment... e.g. Switching identity drivers for an existing single-domain multi-project configuration. Bootstrapping is needed to configure the initial role assignments for the new driver. Since the "cloud admin" concept is not essential for single-domain environments, it may very well not be configured, yet the initial role assignment needs to grant someone the ability to create additional role assignments for all projects in the domain. This would be a domain admin.

2) group-project role assignment... e.g. Where the desired end result is for a group-project role assignment on the cloud admin project, it makes more sense to allow that to be created directly (which could be done without even knowing the password of any user in that group) than to require bootstrapping of a single user and then using their account to create the group assignment and delete the bootstrapped assignment.

3) group-domain role assignment... e.g. combination of #1 and #2

Dolph Mathews (dolph) on 2016-03-07
Changed in keystone:
status: New → Triaged
importance: Undecided → Wishlist
Morgan Fainberg (mdrnstm) wrote :

Generally speaking you could also do the group setup after the initial user is created. The idea behind bootstrap is meant to really just solve chicken-egg problem without encoding defaults into the db migrations.

With all of that said, it's fine to expand keystone-manage bootstrap to be more flexible. Just keep in mind it shouldn't be "the way" to populate everything in keystone - it should be the basic necessities so that the basic setup can be finished.

Matthew Edmonds (edmondsw) wrote :

sure, Morgan. But if I don't want to have a user-project role assignment, it's kind of silly to make me create one, use it to create a group-project role assignment, then delete the user-project role assignment I didn't want. Allowing me to bootstrap with a group-project role assignment is just another way to solve the chicken-egg problem, not a way to populate everything into keystone. I probably want other role assignments, I need to setup the catalog, etc. and all that would still have to be done outside of bootstrapping.

Steve Martinelli (stevemar) wrote :

i don't think this warrants at RC tag since using the ADMIN_TOKEN still works, but we should sort this out or clearly state what we support

Morgan Fainberg (mdrnstm) wrote :

This is not really in the plans. Bootstrap is meant to get you to a place you can setup the rest of the system via the APIs. It is intentionally very narrow. Marking as wont fix.

Changed in keystone:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers