On Mon, Sep 14, 2015 at 2:46 PM, Sofer Athlan-Guyot <sathl...@redhat.com> wrote:
> Morgan Fainberg <morgan.fainb...@gmail.com> writes: > > > On Mon, Sep 14, 2015 at 1:53 PM, Rich Megginson <rmegg...@redhat.com> > > wrote: > > > > > > 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. > > > > > > > > > > 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
__________________________________________________________________________ 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