On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
Hi,
Gilles Dubreuil <gil...@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.
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Bye,
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
