When Keystone is deployed with preferred-api-version=3 it is not possible to downgrade. If deployed with preferred-api-version=2 it is possible to both upgrade to 3 and downgrade again.

[Frode Nordahl]

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.

[Frode Nordahl (fnordahl)]

The default value for default_domain_id in keystone.conf is already 'default'. So the first option for fix is not relevant. The 'default' domain is just not created as a part of the db migration when we are initially set up with identity API v3.

[Frode Nordahl (fnordahl)]

The OpenStack Identity API v3 does not allow you to explicitly set ID of the domain you create.

[Frode Nordahl (fnordahl)]

Another approach could be to change charm-keystone to use identity API v3 for managing Keystone regardless of preferred-api-version setting. Add function that detects API support on Keystone server and use that as basis for which manager class we use.

preferred-api-version=2 setting should of course still export api_version=2 relation data and set up the catalog and endpoints as the user would expect.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/712040
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=0a02c30fe5f4650235519897b71588ae22fa0971
Submitter: Zuul
Branch: master

commit 0a02c30fe5f4650235519897b71588ae22fa0971
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
    doing this we need to move any configuration initially defined
    prior to Miataka forward to the ``templates/mitaka`` folder.

    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
    Closes-Bug: #1837113
    Related-Bug: #1774733
    Closes-Bug: #1648719
    Closes-Bug: #1578678
    Func-Test-Pr: https://github.com/openstack-charmers/zaza-openstack-tests/pull/191
    Change-Id: I23940720c24527ee34149f035c3bdf9ff54812c9