I agree that this is a practical solution, but it feels too much like magic to the end user.
Instead of being a listing of key/value pairs, it's now a relatively arbitrary combination of fields that don't have any inherent meaning. If the types can't be fixed properly then I don't see another way of doing this, but it certainly sets off my usability alarms. Thanks, Trevor On Tue, Mar 18, 2014 at 5:20 AM, David Schmitt <[email protected]> wrote: > 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. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoUPYtoKtQOJhYYEYE%2BNQmP-%3D3%3DsndH5fcE_ovwGsS0oTA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
