support disabling admin_token
Bug #1578678 reported by
Edward Hope-Morley
This bug affects 3 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Keystone Charm |
Fix Released
|
Medium
|
Unassigned | ||
keystone (Juju Charms Collection) |
Invalid
|
Medium
|
Unassigned |
Bug Description
We support providing an admin-token via charm config or having one auto-generated but production envs will want to be able to disable it - http://
Changed in keystone (Juju Charms Collection): | |
milestone: | 16.07 → 16.10 |
Changed in keystone (Juju Charms Collection): | |
milestone: | 16.10 → 17.01 |
Changed in keystone (Juju Charms Collection): | |
status: | New → Triaged |
Changed in charm-keystone: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in keystone (Juju Charms Collection): | |
status: | Triaged → Invalid |
Changed in charm-keystone: | |
milestone: | none → 20.05 |
Changed in charm-keystone: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Reviewed: https:/ /review. opendev. org/712040 /git.openstack. org/cgit/ openstack/ charm-keystone/ commit/ ?id=0a02c30fe5f 4650235519897b7 1588ae22fa0971
Committed: https:/
Submitter: Zuul
Branch: master
commit 0a02c30fe5f4650 235519897b71588 ae22fa0971
Author: Frode Nordahl <email address hidden>
Date: Mon Mar 9 15:06:09 2020 +0100
Replace use of admin_token with Keystone bootstrap
Stop the use of the admin_token and use the bootstrap process
to initialize Keystone instead. Fortunately the implementation
of the bootstrap process is both idempotent when it needs to be
and it can be safely called on an existing deployment.
Subsequently we can migrate by just removing the admin_token
from the configuration and create new credentials for use by
the charm with a call to ``keystone-manage bootstrap``.
Remove configuration templates for versions prior to Mitaka, by mitaka` ` folder.
doing this we need to move any configuration initially defined
prior to Miataka forward to the ``templates/
A side effect of this migration is that newly bootstrapped
deployments will get their ``default`` domain created with a
literal ID of ``default``. Prior to this change third party
software making assumptions about that being the case may have
had issues.
Closes-Bug: #1859844 /github. com/openstack- charmers/ zaza-openstack- tests/pull/ 191 ee34149f035c3bd f9ff54812c9
Closes-Bug: #1837113
Related-Bug: #1774733
Closes-Bug: #1648719
Closes-Bug: #1578678
Func-Test-Pr: https:/
Change-Id: I23940720c24527