On 2014-03-17 15:19, Felix Frank wrote:
On 03/17/2014 08:41 AM, David Schmitt wrote:
as a follow-up to the recent non-unique package name discussion,
I've
noticed two further instances where this is a problem:
* ssh_authorized_key, which is has only the comment ("name") as
namevar. This is obviously easy to avoid in practice, but might
run
into weird edge cases, e.g. blocking proper purge support.
Good point. Note that crontab had different but related issues wrt.
purging. We came up with a workaround then that we can likely apply
to
authorized keys as well, i.e. mangle the titles of generated
resources
into a shape that is unlikely to clash with real-word resources (and
other generated resources).
I've made a quick test and multiple namevars and title patterns do
interact like I have imagined they would:
I've enhanced the type I'm currently working on (see my recent mail),
by adding the second title pattern here:
def self.title_patterns
[
[ /^([-_\w\/]+)\.(\d+)$/ , [ [:parent_interface ],
[:subinterface_number] ] ],
[ /^([-_\w\/]+)$/ , [ [:parent_interface ] ] ], # added
[ //, [] ]
]
end
and now the following notations work all as the respective comments
say:
pan_subinterface {
"ethernet1/5.17":
comment => 'title: ethernet1/5.17';
"ethernet1/5.18":
subinterface_number => '13',
comment => 'title: ethernet1/5.18;
subinterface_number: 13';
"ethernet1/5":
subinterface_number => '14',
comment => 'title: ethernet1/5; parent_interface:
ethernet1/5, subinterface_number: 14';
"flubb_53":
parent_interface => 'ethernet1/5',
subinterface_number => '3'
comment => 'title: flubb_53, parent_interface: ethernet1/5,
subinterface_number: 3';
}
Pan_subinterface['ethernet1/5'] and Pan_subinterface['ethernet1/5.18']
are very misleading titles in this specific case, but would be poster
childs for resources like cron or authorized keys, where the
non-colliding use case is much less confusing, because the title would
map to a command or comment.
Example using ssh_authorized_key:
# current situation
ssh_authorized_key {
# no user: key goes to root
"some_app":
ensure => present,
key => "...";
# specify user as property
"some_user_app":
ensure => present,
key => "...",
user => "flubb";
# unique title and name, specify user as property, comment will be
"flubb: power_key"
"flubb: power_key":
ensure => present,
key => "...",
user => "flubb";
# unique title and name, specify user as property, comment will be
"buzz: power_key"
"buzz: power_key":
ensure => present,
key => "...",
user => "buzz";
# title collision although configured for different user
"buzz: power_key":
ensure => present,
key => "...",
user => "froz";
}
# with title patterns and multiple namevars
ssh_authorized_key {
# no user: key goes to root
"some_app":
ensure => present,
key => "...";
# specify user as property
"some_user_app":
ensure => present,
key => "...",
user => "flubb";
# parse user "flubb" from title, comment will be "power_key"
"flubb: power_key":
ensure => present,
key => "...";
# parse user "buzz" from title, comment will be "power_key"
"buzz: power_key":
ensure => present,
key => "...";
# title collision although configured for different user
"buzz: power_key":
ensure => present,
key => "...",
user => "froz";
}
There seem to be some gains, but I'm not sure, whether they translate
to enough practical savings for the migration effort.
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/e7a6f4a7451dcf0704e39062fa34be79%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.
