| 2016-12-09 07:48:31 |
Frode Nordahl |
bug |
|
|
added bug |
| 2016-12-09 07:49:51 |
Frode Nordahl |
description |
The underlying issue here is:
- When first deployed with preferred-api-version=2 the default domain is created with id 'default'.
- When first deployed with preferred-api-version=3 the default domain is created with random UUID.
- When downgrading API version in deployment with random UUID special code paths in Keystone for
backwards compatibility are not exercised.
- Downgrade of API version from deployment first deployed with preferred-api-version=2, then
upgraded and then downgraded again succeeds.
Possible ways to fix this:
- Always set default_domain_id in keystone.conf
Cons:
- When downgrading preferred-api-version, the API client that the charm itself uses is also
downgraded to use v2. This client is in practice unable to get information about domains
and thus unable to get the UUID of the default domain.
- Explicitly set ID of default domain to 'default' when creating it initially.
- Extend Keystone manager interfaces to allow this. |
The underlying issue here is:
- When first deployed with preferred-api-version=2 the default domain is created with id 'default'.
- When first deployed with preferred-api-version=3 the default domain is created with random UUID.
- When downgrading API version in deployment with random UUID special code
paths in Keystone for backwards compatibility are not exercised.
- Downgrade of API version from deployment first deployed with
preferred-api-version=2, then upgraded and then downgraded again
succeeds.
Possible ways to fix this:
- Always set default_domain_id in keystone.conf
Cons:
- When downgrading preferred-api-version, the API client that the charm
itself uses is also downgraded to use v2. This client is in practice
unable to get information about domains and thus unable to get the
UUID of the default domain.
- Explicitly set ID of default domain to 'default' when creating it
initially.
- Extend Keystone manager interfaces to allow this. |
|
| 2016-12-09 07:50:03 |
Frode Nordahl |
keystone (Juju Charms Collection): assignee |
|
Frode Nordahl (fnordahl) |
|
| 2016-12-13 12:40:12 |
James Page |
keystone (Juju Charms Collection): status |
New |
Triaged |
|
| 2016-12-13 12:40:14 |
James Page |
keystone (Juju Charms Collection): importance |
Undecided |
Wishlist |
|
| 2017-02-23 18:55:26 |
James Page |
charm-keystone: importance |
Undecided |
Wishlist |
|
| 2017-02-23 18:55:26 |
James Page |
charm-keystone: status |
New |
Triaged |
|
| 2017-02-23 18:55:26 |
James Page |
charm-keystone: assignee |
|
Frode Nordahl (fnordahl) |
|
| 2017-02-23 18:55:27 |
James Page |
keystone (Juju Charms Collection): status |
Triaged |
Invalid |
|
| 2017-04-25 08:47:39 |
Sandor Zeestraten |
bug |
|
|
added subscriber Sandor Zeestraten |
| 2017-06-28 09:06:33 |
Frode Nordahl |
description |
The underlying issue here is:
- When first deployed with preferred-api-version=2 the default domain is created with id 'default'.
- When first deployed with preferred-api-version=3 the default domain is created with random UUID.
- When downgrading API version in deployment with random UUID special code
paths in Keystone for backwards compatibility are not exercised.
- Downgrade of API version from deployment first deployed with
preferred-api-version=2, then upgraded and then downgraded again
succeeds.
Possible ways to fix this:
- Always set default_domain_id in keystone.conf
Cons:
- When downgrading preferred-api-version, the API client that the charm
itself uses is also downgraded to use v2. This client is in practice
unable to get information about domains and thus unable to get the
UUID of the default domain.
- Explicitly set ID of default domain to 'default' when creating it
initially.
- Extend Keystone manager interfaces to allow this. |
The underlying issue here is:
- When first deployed with preferred-api-version=2 the default domain is created with id 'default'.
- When first deployed with preferred-api-version=3 the default domain is created with random UUID.
- When downgrading API version in deployment with random UUID special code
paths in Keystone for backwards compatibility are not exercised.
- Downgrade of API version from deployment first deployed with
preferred-api-version=2, then upgraded and then downgraded again
succeeds. |
|
| 2020-03-18 16:44:05 |
OpenStack Infra |
charm-keystone: status |
Triaged |
Fix Committed |
|
| 2020-05-19 12:53:21 |
James Page |
charm-keystone: milestone |
|
20.05 |
|
| 2020-05-21 20:11:41 |
David Ames |
charm-keystone: status |
Fix Committed |
Fix Released |
|
