Open Stack

On 08/05/2015 07:48 PM, Gilles Dubreuil wrote:
>
> On 06/08/15 10:16, Jamie Lennox wrote:
>>
>> ----- Original Message -----
>>> From: "Adam Young" <ayoung at redhat.com>
>>> To: openstack-dev at lists.openstack.org
>>> Sent: Thursday, August 6, 2015 1:03:55 AM
>>> Subject: Re: [openstack-dev] [puppet][keystone] To always use or not use domain name?
>>>
>>> On 08/05/2015 08:16 AM, Gilles Dubreuil wrote:
>>>> While working on trust provider for the Keystone (V3) puppet module, a
>>>> question about using domain names came up.
>>>>
>>>> Shall we allow or not to use names without specifying the domain name in
>>>> the resource call?
>>>>
>>>> I have this trust case involving a trustor user, a trustee user and a
>>>> project.
>>>>
>>>> For each user/project the domain can be explicit (mandatory):
>>>>
>>>> trustor_name::domain_name
>>>>
>>>> or implicit (optional):
>>>>
>>>> trustor_name[::domain_name]
>>>>
>>>> If a domain isn't specified the domain name can be assumed (intuited)
>>>> from either the default domain or the domain of the corresponding
>>>> object, if unique among all domains.
>>> If you are specifying project by name, you must specify domain either
>>> via name or id.  If you specify proejct by ID, you run the risk of
>>> conflicting if you provide a domain speciffiedr (ID or name).
>>>
>>>> Although allowing to not use the domain might seems easier at first, I
>>>> believe it could lead to confusion and errors. The latter being harder
>>>> for the user to detect.
>>>>
>>>> Therefore it might be better to always pass the domain information.
>>> Probably a good idea, as it will catch if you are making some
>>> assumption.  IE, I say  DomainX  ProejctQ  but I mean DomainQ ProjectQ.
>> Agreed. Like it or not domains are a major part of using the v3 api and if you want to use project names and user names we should enforce that domains are provided.
>> Particularly at the puppet level (dealing with users who should understand this stuff) anything that tries to guess what the user means is a bad idea and going to lead to confusion when it breaks.
>>
> I totally agree.
>
> Thanks for participating

Would someone who actually has to deploy/maintain puppet manifests and 
supporting code chime in here?  How do you feel about having to ensure 
that every domain scoped Keystone resource name must end in "::domain"?  
At the very least, if not using domains, and not changing the default 
domain, you would have to ensure "something::Default" _everywhere_ - and 
I do mean everywhere - every user and tenant name use, including in 
keystone_user_role, and in other, higher level classes/defines that 
refer to keystone users and tenants.

Anyone?

I also wonder how the Ansible folks are handling this, as they move to 
support domains and other Keystone v3 features in openstack-ansible code?


>
>>>> I believe using the full domain name approach is better.
>>>> But it's difficult to tell because in puppet-keystone and
>>>> puppet-openstacklib now rely on python-openstackclient (OSC) to
>>>> interface with Keystone. Because we can use OSC defaults
>>>> (OS_DEFAULT_DOMAIN or equivalent to set the default domain) doesn't
>>>> necessarily makes it the best approach. For example hard coded value [1]
>>>> makes it flaky.
>>>>
>>>> [1]
>>>> https://github.com/openstack/python-openstackclient/blob/master/openstackclient/shell.py#L40
>>>>
>>>> To help determine the approach to use, any feedback will be appreciated.
>>>>
>>>> Thanks,
>>>> Gilles
>>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev