Open Stack

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.

> 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.

>   Cons
>     - Titles have no meaning!
>     - Cases where 2 or more resources could exists
>     - More difficult to debug
>     - 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.

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.

>
> Finally
> ------
> Thanks for reading that far!
> To choose, please provide feedback with more pros/cons, examples and
> your vote.
>
> Thanks,
> Gilles
>
>
> PS:
> [1] https://groups.google.com/forum/#!topic/puppet-dev/CVYwvHnPSMc
>
> __________________________________________________________________________
> 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

Bye,
-- 
Sofer.