Open Stack

Morgan Fainberg <morgan.fainberg at gmail.com> writes:

> On Mon, Sep 14, 2015 at 1:53 PM, Rich Megginson <rmeggins at redhat.com>
> wrote:
>
>     
>     On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>     
>     Hi,
>         
>         Gilles Dubreuil <gilles at redhat.com> writes:
>         
>                 A. The 'composite namevar' approach:
>             
>             keystone_tenant {'projectX::domainY': ... }
>             B. The 'meaningless name' approach:
>             
>             keystone_tenant {'myproject': name='projectX', domain=>'domainY',
>             ...}
>             
>             Notes:
>             - Actually using both combined should work too with the
>             domain
>             supposedly overriding the name part of the domain.
>             - Please look at [1] this for some background between the
>             two approaches:
>             
>             The question
>             -------------
>             Decide between the two approaches, the one we would like
>             to retain for
>             puppet-keystone.
>             
>             Why it matters?
>             ---------------
>             1. Domain names are mandatory in every user, group or
>             project. Besides
>             the backward compatibility period mentioned earlier, where
>             no domain
>             means using the default one.
>             2. Long term impact
>             3. Both approaches are not completely equivalent which
>             different
>             consequences on the future usage.
>         I can't see why they couldn't be equivalent, but I may be
>         missing
>         something here.
>
>     
>     I think we could support both. I don't see it as an either/or
>     situation.
>     
>         
>                 4. Being consistent
>             5. Therefore the community to decide
>             
>             Pros/Cons
>             ----------
>             A.
>         I think it's the B: meaningless approach here.
>         
>                 Pros
>             - Easier names
>         That's subjective, creating unique and meaningful name don't
>         look easy
>         to me.
>
>     The point is that this allows choice - maybe the user already has
>     some naming scheme, or wants to use a more "natural" meaningful
>     name - rather than being forced into a possibly "awkward" naming
>     scheme with "::"
>     
>     keystone_user { 'heat domain admin user':
>     name => 'admin',
>     domain => 'HeatDomain',
>     ...
>     }
>     
>     keystone_user_role {'heat domain admin user@::HeatDomain':
>     roles => ['admin']
>     ...
>     }
>     
>         
>                 Cons
>             - Titles have no meaning!
>
>     They have meaning to the user, not necessarily to Puppet.
>     
>                 - Cases where 2 or more resources could exists
>
>     This seems to be the hardest part - I still cannot figure out how
>     to use "compound" names with Puppet.
>     
>                 - More difficult to debug
>
>     More difficult than it is already? :P
>     
>     
>     
>                 - Titles mismatch when listing the resources
>             (self.instances)
>             
>             B.
>             Pros
>             - Unique titles guaranteed
>             - No ambiguity between resource found and their title
>             Cons
>             - More complicated titles
>             My vote
>             --------
>             I would love to have the approach A for easier name.
>             But I've seen the challenge of maintaining the providers
>             behind the
>             curtains and the confusion it creates with name/titles and
>             when not sure
>             about the domain we're dealing with.
>             Also I believe that supporting self.instances consistently
>             with
>             meaningful name is saner.
>             Therefore I vote B
>         +1 for B.
>         
>         My view is that this should be the advertised way, but the
>         other method
>         (meaningless) should be there if the user need it.
>         
>         So as far as I'm concerned the two idioms should co-exist.
>         This would
>         mimic what is possible with all puppet resources. For instance
>         you can:
>         
>         file { '/tmp/foo.bar': ensure => present }
>         
>         and you can
>         
>         file { 'meaningless_id': name => '/tmp/foo.bar', ensure =>
>         present }
>         
>         The two refer to the same resource.
>
>     
>     Right.
>     
>         
>         But, If that's indeed not possible to have them both, then I
>         would keep
>         only the meaningful name.
>         
>         
>         As a side note, someone raised an issue about the delimiter
>         being
>         hardcoded to "::". This could be a property of the resource.
>         This
>         would enable the user to use weird name with "::" in it and
>         assign a "/"
>         (for instance) to the delimiter property:
>         
>         Keystone_tenant { 'foo::blah/bar::is::cool': delimiter => "/",
>         ... }
>         
>         bar::is::cool is the name of the domain and foo::blah is the
>         project.
>
>     That's a good idea. Please file a bug for that.
>     
>     
>     
>
> I'm not sure I see a benefit to notation like:
> Keystone_tenant { 'foo::blah/bar::is::cool': delimiter => "/", ... }

Currently keystone v3 is doing domain using name and the "::" separator,
so that can be classified as an existing bug.  If the decision is taken
to remove the support for such notation (ie, <name>::<domain>,
'composite namevar' approach) then the delimiter parameter will be
useless.  If we continue to support that notation, then this would
enable the user to use any characters (minus their own chosen delimiter)
in their names.

> Overall option below just looks more straightforward (and requires
> less logic to convert to something useful). However, I admit I am not
> an expert in puppet conventions:
>
> Keystone_tenant { 'foo::blah" domain => "bar::is::cool'", ... }

This would be some kind of a mix between the two options proposed by
Gilles, if I'm not mistaken.  The name would be the project and the
domain would be a property.  So the name wouldn't be meaningless, but it
wouldn't be fully qualified neither.  So many choices :)

>
> --Morgan
>
> __________________________________________________________________________
> 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

-- 
Sofer Athlan-Guyot