Open Stack

On Mon, Sep 14, 2015 at 2:46 PM, Sofer Athlan-Guyot <sathlang at redhat.com>
wrote:

> 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 :)


I wasn't meaning to toss a new option onto the pile, I was just quoting
from a previous email.

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150915/8e52ac1c/attachment.html>