On Thursday, June 2, 2011 at 10:16 AM, Jacob Helwig wrote: > We currently have to feature requests to add similar (or at least > overlapping) functionality to the Package type. > > #2247[1] - enablerepo and disablerepo for yum type > > #4113[2] - Provide a generic "options"-style parameter for packages. > > It seems like having #4113 would remove the need for having #2247, but I > wanted to get some wider opinions to make sure I wasn't ignoring some > use-case that would make this not the case. > > Personally, I think we should move forward on #4113 instead of #2247, > since #4113 seems like the more general solution, and isn't tied > directly to the yum provider. > > #2247 does currently have some code submitted for it, however it > requires a signed CLA before we can accept it. While no code has been > written for #4113 yet, it doesn't look like it would actually be that > much work to do. > > Thoughts? Opinions? Comments? > It looks like the crux of this problem is that many, many providers add their own, fairly unique, capabilities. We then try to model all of these capabilities in the type, and end up with a package type that has ~15 parameters, many of which are ignored on almost all providers, and no properties.
And yet we have no real ability to add provider-specific attributes, aside from adding them to the type, with an associated feature, and declaring our provider as the only one that supports that feature. So my generic proposal is that we add some better way to do that. To keep the definition of a resource consistent across providers, this should only allow additional parameters (data) to be specified, and not properties. I have a few ideas for this: 1) Add an 'options' or 'data' or similar metaparameter which accepts a hash. This would basically be a place to add arbitrary data accessible to the provider. Thus, for the enablerepo example, it would just be a key/value in the options hash. Any provider is free to use or ignore it as desired. A big problem with this is there's no real validation for which keys are allowed, or what they must look like, which leads us to: 2) As 1, but with an ability for a provider to specify the options acceptable. In this case, a provider would have some method for declaring a legal option, and its validation and/or munging. But in this case, what's the difference between a parameter and an option? Apparently only where/how we declare and specify them. Although, there may be some benefit to distinguishing generic type parameters from provider-specific options. 3) As 2, but remove the concept of parameters. This is one possible way to reconcile the difference between parameters and options. But is there really an advantage to wrapping all of our data which is essentially parameters in a hash? Maybe, for distinguishing parameters from properties, but probably not. 4) As 2, but instead using something like newparam on provider. This is similar to the previous idea, in that it unifies "options" and "parameters", but in the other direction. In addition to specifying generic type parameters, also add the ability to specify provider-specific parameters. This has the advantage of not requiring any changes to existing manifests using provider parameters. It has the disadvantage that we can't really validate provider parameters on the master (though we've talked about removing validation on the master anyway). Since I can't even decide which of my own four suggestions I prefer, please poke holes in as many of them as you can to ease my mental burden. :) > [1] http://projects.puppetlabs.com/issues/2247 > [2] http://projects.puppetlabs.com/issues/4113 > > -- > Jacob Helwig -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
