set default domain dynamically

[Richard Megginson]

In order to set the default_domain_id, Keystone must first be running, and you must issue a domain create command to create the default domain and retrieve the id of the domain in order to set it in keystone.conf, then restart Keystone for the change to take effect. This causes problems for puppet based installers because puppet does not want to restart Keystone more than once.

Instead, what would be preferable is the ability to set the default_domain_id dynamically.

For example, when using `openstack`, add an option `--default-domain`::

    $ openstack domain create defdomain --enable --description 'my default domain' --default-domain

This would create the domain and make it the default domain, without having to restart Keystone for the change in default_domain_id to take effect.

It doesn't have to be implemented this way, just a suggestion, but the method to set the default_domain_id should be exposed via the `openstack` cli.

[Dolph Mathews (dolph)]

Does keystone-manage db_sync not create the default domain automatically based on the values in keystone.conf anymore?

[Richard Megginson (rmeggins)]

I guess keystone-manage db_sync creates the domain named 'Default' with the uuid 'default'? But what if you want a different, new domain to be the default? Then you have to do this::

    # domid=`openstack domain create newdomain --format value`
    # openstack-config --set /etc/keystone/keystone.conf identity default_domain_id $domid
    # service keystone restart

Unless I'm missing something?

[Richard Megginson (rmeggins)]

The bug is still `Incomplete` - do you still require more information from me?

[Adam Young (ayoung)]

Default domain is a "forward compat" feature necessary to let V2 continue to work in a V3 aware keystone.

The default domain is a very important domain, and should be part of the core configuration. Changing that on the fly will change the meaning of the V2 tokens, and is not something to be done lightly.

In the future, I would like to drop default domain, but that can only be done after V2 is deprecated.

I realize making config changes like this is painful for Puppet, but it is correct based on the way the web servers work.

Probably not going to fix.

[Richard Megginson (rmeggins)]

> The default domain is a very important domain, and should be part of the core configuration. Changing that on the fly will change the meaning of the V2 tokens, and is not something to be done lightly.

Right. That's why, if the user wants to change the default domain, it must be done as the very first thing, as the creation of all other domain scoped resources will depend on it. Puppet-keystone doesn't want to "change it on the fly", if that means "change it at any time and have Keystone just 'do the right thing'". Puppet-keystone wants it for the very specific case where a user wants to have a default domain other than 'Default', that will be configured before anything else is created, and would like to be able to do this without having to 'configure Keystone with bootstrap config' -> 'start Keystone' -> 'create domain' -> 'get uuid of created domain' -> 'set default_domain_id' -> 'restart Keystone'

A couple of other different ways to solve this particular problem:

1) Allow clients to specify the UUID of the resource for Keystone to use, rather than having to create the resource, then get back the UUID. This would solve several problems (e.g. trusts) as well as this particular problem.

2) Allow setting the 'default_domain_name' instead of/as an alternative to setting the 'default_domain_id'.

In either 1) or 2), Keystone would be started with a reference to a domain that didn't actually exist yet, but would be created just after startup.

[Dolph Mathews (dolph)]

Richard: Thank you for documenting the actual problematic use case here.

On solution (2), can you not just PATCH /v3/domains/default with the custom domain name? I don't see why you'd need to create a second domain.

[Richard Megginson (rmeggins)]

> On solution (2), can you not just PATCH /v3/domains/default with the custom domain name? I don't see why you'd need to create a second domain.

I'll need to see if that will solve the problem. Puppet-keystone uses the `openstack` cli - Steve M./Dean T. - does the openstack command line tool allow us to do this?

[Richard Megginson (rmeggins)]

moved bug/rfe to python-openstackclient

python-openstackclient should support the keystone default domain api

[Dolph Mathews (dolph)]

It does.

  $ openstack domain set default --name=<new-name> --description=<new-description>

Where 'default' is the value from keystone.conf [identity] default_domain_id and db_sync has already been run to create that domain.

[Richard Megginson (rmeggins)]

thanks - opened https://bugs.launchpad.net/puppet-keystone/+bug/1490029 to implement this in puppet-keystone