<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 2:46 PM, Sofer Athlan-Guyot <span dir="ltr"><<a href="mailto:sathlang@redhat.com" target="_blank">sathlang@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> writes:<br>
<br>
> On Mon, Sep 14, 2015 at 1:53 PM, Rich Megginson <<a href="mailto:rmeggins@redhat.com">rmeggins@redhat.com</a>><br>
> wrote:<br>
><br>
><br>
>     On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:<br>
><br>
>     Hi,<br>
><br>
>         Gilles Dubreuil <<a href="mailto:gilles@redhat.com">gilles@redhat.com</a>> writes:<br>
><br>
>                 A. The 'composite namevar' approach:<br>
><br>
>             keystone_tenant {'projectX::domainY': ... }<br>
>             B. The 'meaningless name' approach:<br>
><br>
>             keystone_tenant {'myproject': name='projectX', domain=>'domainY',<br>
>             ...}<br>
><br>
>             Notes:<br>
>             - Actually using both combined should work too with the<br>
>             domain<br>
>             supposedly overriding the name part of the domain.<br>
>             - Please look at [1] this for some background between the<br>
>             two approaches:<br>
><br>
>             The question<br>
>             -------------<br>
>             Decide between the two approaches, the one we would like<br>
>             to retain for<br>
>             puppet-keystone.<br>
><br>
>             Why it matters?<br>
>             ---------------<br>
>             1. Domain names are mandatory in every user, group or<br>
>             project. Besides<br>
>             the backward compatibility period mentioned earlier, where<br>
>             no domain<br>
>             means using the default one.<br>
>             2. Long term impact<br>
>             3. Both approaches are not completely equivalent which<br>
>             different<br>
>             consequences on the future usage.<br>
>         I can't see why they couldn't be equivalent, but I may be<br>
>         missing<br>
>         something here.<br>
><br>
><br>
>     I think we could support both. I don't see it as an either/or<br>
>     situation.<br>
><br>
><br>
>                 4. Being consistent<br>
>             5. Therefore the community to decide<br>
><br>
>             Pros/Cons<br>
>             ----------<br>
>             A.<br>
>         I think it's the B: meaningless approach here.<br>
><br>
>                 Pros<br>
>             - Easier names<br>
>         That's subjective, creating unique and meaningful name don't<br>
>         look easy<br>
>         to me.<br>
><br>
>     The point is that this allows choice - maybe the user already has<br>
>     some naming scheme, or wants to use a more "natural" meaningful<br>
>     name - rather than being forced into a possibly "awkward" naming<br>
>     scheme with "::"<br>
><br>
>     keystone_user { 'heat domain admin user':<br>
>     name => 'admin',<br>
>     domain => 'HeatDomain',<br>
>     ...<br>
>     }<br>
><br>
>     keystone_user_role {'heat domain admin user@::HeatDomain':<br>
>     roles => ['admin']<br>
>     ...<br>
>     }<br>
><br>
><br>
>                 Cons<br>
>             - Titles have no meaning!<br>
><br>
>     They have meaning to the user, not necessarily to Puppet.<br>
><br>
>                 - Cases where 2 or more resources could exists<br>
><br>
>     This seems to be the hardest part - I still cannot figure out how<br>
>     to use "compound" names with Puppet.<br>
><br>
>                 - More difficult to debug<br>
><br>
>     More difficult than it is already? :P<br>
><br>
><br>
><br>
>                 - Titles mismatch when listing the resources<br>
>             (self.instances)<br>
><br>
>             B.<br>
>             Pros<br>
>             - Unique titles guaranteed<br>
>             - No ambiguity between resource found and their title<br>
>             Cons<br>
>             - More complicated titles<br>
>             My vote<br>
>             --------<br>
>             I would love to have the approach A for easier name.<br>
>             But I've seen the challenge of maintaining the providers<br>
>             behind the<br>
>             curtains and the confusion it creates with name/titles and<br>
>             when not sure<br>
>             about the domain we're dealing with.<br>
>             Also I believe that supporting self.instances consistently<br>
>             with<br>
>             meaningful name is saner.<br>
>             Therefore I vote B<br>
>         +1 for B.<br>
><br>
>         My view is that this should be the advertised way, but the<br>
>         other method<br>
>         (meaningless) should be there if the user need it.<br>
><br>
>         So as far as I'm concerned the two idioms should co-exist.<br>
>         This would<br>
>         mimic what is possible with all puppet resources. For instance<br>
>         you can:<br>
><br>
>         file { '/tmp/foo.bar': ensure => present }<br>
><br>
>         and you can<br>
><br>
>         file { 'meaningless_id': name => '/tmp/foo.bar', ensure =><br>
>         present }<br>
><br>
>         The two refer to the same resource.<br>
><br>
><br>
>     Right.<br>
><br>
><br>
>         But, If that's indeed not possible to have them both, then I<br>
>         would keep<br>
>         only the meaningful name.<br>
><br>
><br>
>         As a side note, someone raised an issue about the delimiter<br>
>         being<br>
>         hardcoded to "::". This could be a property of the resource.<br>
>         This<br>
>         would enable the user to use weird name with "::" in it and<br>
>         assign a "/"<br>
>         (for instance) to the delimiter property:<br>
><br>
>         Keystone_tenant { 'foo::blah/bar::is::cool': delimiter => "/",<br>
>         ... }<br>
><br>
>         bar::is::cool is the name of the domain and foo::blah is the<br>
>         project.<br>
><br>
>     That's a good idea. Please file a bug for that.<br>
><br>
><br>
><br>
><br>
> I'm not sure I see a benefit to notation like:<br>
> Keystone_tenant { 'foo::blah/bar::is::cool': delimiter => "/", ... }<br>
<br>
</div></div>Currently keystone v3 is doing domain using name and the "::" separator,<br>
so that can be classified as an existing bug.  If the decision is taken<br>
to remove the support for such notation (ie, <name>::<domain>,<br>
'composite namevar' approach) then the delimiter parameter will be<br>
useless.  If we continue to support that notation, then this would<br>
enable the user to use any characters (minus their own chosen delimiter)<br>
in their names.<br>
<span class=""><br>
> Overall option below just looks more straightforward (and requires<br>
> less logic to convert to something useful). However, I admit I am not<br>
> an expert in puppet conventions:<br>
><br>
> Keystone_tenant { 'foo::blah" domain => "bar::is::cool'", ... }<br>
<br>
</span>This would be some kind of a mix between the two options proposed by<br>
Gilles, if I'm not mistaken.  The name would be the project and the<br>
domain would be a property.  So the name wouldn't be meaningless, but it<br>
wouldn't be fully qualified neither.  So many choices :)</blockquote><div><br></div><div>I wasn't meaning to toss a new option onto the pile, I was just quoting from a previous email.</div><div><br></div><div>--Morgan </div></div><br></div></div>