On 2014-03-18 10:33, Felix Frank wrote:
On 03/18/2014 10:20 AM, David Schmitt wrote:
# parse user "flubb" from title, comment will be "power_key"
"flubb: power_key":
ensure => present,
key => "...";
This kinda made me frown. What would this manifest express then:
Ssh_authorized_key { ensure => present, user => "customer" }
ssh_authorized_key { "admin: masterkey": key => ... }
(Also, what would a user expect it to express?)
This is indeed ugly. I've only discovered the current behaviour by
experimentation. This is definitely something that should be fixed in
one way or the other:
* title matches take priority, or
* properties set directly and via title are forbidden.
As for "migration"...this would be us looking at deprecating key
names
of the proposed form first. Granted, those are unlikely picks, but
any
user that *is* afflicted by such a deprecation will have to make some
handstands to cleanly move to a different naming scheme.
Now that I think more about it, I feel obliged to point out that adding
a second namevar and adding title_patterns are two separate issues.
Adding the namevar (and - IIRC - changing the Type#name getter) without
adding title_patterns for comment AND user syntax would create this
situation:
# with multiple namevars, but no title pattern
ssh_authorized_key {
# no user: key goes to root, use title as comment
"some_app":
ensure => present,
key => "...";
# specify user as property, use title as comment
"some_user_app":
ensure => present,
key => "...",
user => "flubb";
# potentially conflicting resources
# specify user as property, use title as comment
"flubb: power_key":
ensure => present,
user => flubb,
key => "...";
# use title without specific meaning
"buzz: power_key":
ensure => present,
user => flubb,
comment => power_key,
key => "...";
# use title without specific meaning, collision with last resource
because of title
"buzz: power_key":
ensure => present,
user => froz,
comment => power_key,
key => "...";
# use title without specific meaning, collision with last resource
because of properties
# not tested empircally
"froz: power_key":
ensure => present,
user => froz,
comment => power_key,
key => "...";
}
This becomes more verbose, but would not require a migration. Having
written it down, I'm not sure what multiple namevars would bring to the
table. From my amateurish reading of Puppet::Type, they are used
internally to automatically distinguish resources. The code around this
is not very clear, or clearly documented.
Regards, David
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/6d62c2967a85ee47f6bd63be9cd3e6d7%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.
