Cannot modify the domain of a group

[Gilles Dubreuil]

Unable to modify an existing group's domain property.

The following example shows the description property can be updated but its domain.

There are no errors or warnings from keystone logs.
Tested using python-openstackclient 1.5.0 - Openstack Kilo - 2015.1.6

Maybe it's related to bug https://bugs.launchpad.net/python-openstackclient/+bug/1475127 if it's using the group's id behind.

-----------------------------
# openstack domain list -f csv
"ID","Name","Enabled","Description"
"43c0586acd1b48b5ad544600414700fb","admin_domain",True,"Domain for admin v3 users"
"71867e7a881348bab486ac32c0381b49","service_domain",True,"Domain for admin v3 users"
"default","Default",True,"Owns users and tenants (i.e. projects) available on Identity API v2."
"fc37e606ad1342e6868c97ef6a34b8a6","thedomain",True,"thetest"

# openstack group create mygroup -f shell
description=""
domain_id="default"
id="d9b4956792454d92ba20a7c5b0457344"
name="mygroup"

# openstack group set mygroup --description foo

# openstack group set mygroup --domain thedomain
ERROR: openstack No group with a name or ID of 'mygroup' exists.

# openstack group set mygroup --domain fc37e606ad1342e6868c97ef6a34b8a6
ERROR: openstack No group with a name or ID of 'mygroup' exists.
-----------------------------

[Steve Martinelli (stevemar)]

we need a second domain option here, maybe --new-domain?

--domain should be used to find the group if --group is a name.

--new-domain should be used to set a new domain on the group (found using --domain and --group)

[Gilles Dubreuil (gdubreui)]

@Stevemar,

Maybe I'm missing something and I'm completely wrong but once a group has been created and therefore attached to domain, whether default or specified with --domain, then the group is attached to a domain, why --domain could not be used to override the domain value with a new one. Like when overriding the description field, there is no need for a new-description parameter.

[Steve Martinelli (stevemar)]

@gilles

we need two here because...

  $ openstack group set myGroup --domain original --new-domain newDomain

I agree that for setting a new domain all you need is the domain. The problem becomes trying to find the original group to modify.

Groups are domain scoped, so you can have myGroup in the `original` domain, and `domainx` and `domainy`...

If you were to specify just the UUID, it would be fine, but if submitting a name, then we need to also know what domain you are referring to.

[Richard Megginson (rmeggins)]

AFAIK, none of the keystone domain scoped resources allow you to change the domain - not keystone_user or keystone_tenant.

The --domain argument to openstack group set is _not_ for the purpose of modifying the domain of the group, it is for specifying the domain to which the group named by `name` belongs. Is this how it works now? If so, then we can close this bug as invalid. If not, then we need to get this fixed, but perhaps not right away, as the puppet-keystone code should use the `id` instead of the `name` of the group, in which case we don't need to specify the domain. Of course, using the `id` doesn't work right now because of https://bugs.launchpad.net/python-openstackclient/+bug/1475127

[Gilles Dubreuil (gdubreui)]

I understand groups have a naming scope limited by domain.

I now understand the --domain is the scope.

Therefore a --new-domain parameter would be necessary to change the group to another domain if deemed needed.

[Gilles Dubreuil (gdubreui)]

I'm not sure what are the real use cases to move a group to another domain.

What I'm sure about is the user is always right and we as humans makes mistake (and as mammals, learn from them).
Thus to be able to move a group to another domain after being wrongly assigned and after hundred of use have been assigned to it. Easier to move the group than starting from scratch.

Now I initially triggered this request from a Puppet viewpoint where manipulating goup resources usually also include modifying the resource, whether the user wants to use it or not. The latter being the real question I don't have the answer.

[jiaxi (tjxiter)]

@Steve Martinelli (stevemar):

--new-domain should not exist.

Because you can update the domain of group very happy for the first time.
But think about the second time or later,can you very the command as usual?

First time
openstack group set mygroup --domain domainA --new-domain domainB

Second time
openstack group set mygroup --domain domainA --new-domain domainC

Last time
openstack group set mygroup --domain domainA --new-domain domainD

it's not very proper.

In my opinion, --domain is enough and can be updated.

[Steve Martinelli (stevemar)]

Try it out for yourself and see if it works

[Steve Martinelli (stevemar)]

The second time would fail, since OSC won't be able to find the domain

[jiaxi (tjxiter)]

The second time would fail, so I don't want to add --new-domain.

A --domain is enough.

[jiaxi (tjxiter)]

Hello Steve Martinelli (stevemar) ,

I want to do it like this.

1. when specify group as id
openstack group set 86ee484cb6504db5a72d0dad63794195 --domain thedomain

we can user group_id to find the domain_id , then we can change

2. when specify group as name
openstack group set mygroup --domain thedomain

we can raise en exception, tell the user "If you want to change the domain of a group, please provide the group_id instead of name"

And This will not change the other cmd about group set.

Do you agree with me ?

[jiaxi (tjxiter)]

The comment can't be edit. It's not a good design.

At the first line of #11 should be Hello @Steve Martinelli (stevemar),

[Steve Martinelli (stevemar)]

@jiaxi, that's inconsistent with all our other commands that work with Name or ID, so specifying the ID is not good enough.

In fact, the docs even say that group set, should work with Name or ID: http://docs.openstack.org/developer/python-openstackclient/command-objects/group.html#group-set

  <group>
    Group to modify (name or ID)

The point is, you should *not* need to do 2 commands before doing a set or a delete.

How about using group-domain?

$ openstack group create mygroup --domain mydomain

$ openstack group set mygroup --group-domain mydomain --domain newdomain

As a user, I don't want to have to remember any UUIDs, when I have a name that's handy

[jiaxi (tjxiter)]

@Steve Martinelli (stevemar)

1. the docs can be updated
2. if use
$ openstack group set mygroup --group-domain mydomain --domain newdomain

the --group-domain can have impact about the other cmd.
What's more, when you want to change domain for the second time or more, please look at #7

3.As a user, I don't want to have to remember any UUIDs.
You need't remember uuid, because you can run some cmd to get it.

[Steve Martinelli (stevemar)]

Group NAMES are DOMAIN SCOPED.

If you are referring to a group NAME, you need to specify what DOMAIN it lives in.
Having users look up UUIDs is wrong.

We will be adding an option to lookup a domain.

I strongly suggest you read the Identity APIs http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#groups-v3-groups

[Sean Perry (sean-perry-a)]

This is a deeper change than just OSC. Below is an attempt to twiddle both the description and the domain_id.

    $ curl -k -X PATCH -H 'Content-type: application/json' -H 'X-Auth-Token: password' -d '{ "group": { "description": "Group1 for BB (edited)", "domain_id": "f5cc062ba0ee4ce1814b35d606b4babc" } }' https://keystone.example.com:35357/v3/groups/92304e27d95d47db9fe804c97348cf6c

    {
        "error": {
            "code": 400,
            "message": "Cannot change Domain ID",
            "title": "Bad Request"
        }
    }

The request is caught by V3Controller::_require_matching_domain_id().

[Lin Hua Cheng (lin-hua-cheng)]

Domains are containers of Groups and Users, I don't agree allowing change of Domain for Group/User.

I don't see a logical point of allowing it, it would just cause unexpected behavior in the system. Allowing this would result to an implicit cross domain role assignment.

[Lin Hua Cheng (lin-hua-cheng)]

If you want to move the group to a different, this needs to be some sort of a transfer workflow. Domain ID are immutable for Group and User to maintain data integrity.