Issue #4113 has been updated by Daniel Pittman. Assignee deleted (Daniel Pittman)
Jo Rhett wrote: > Why has this received so little love? There's already a working example for > yum FYI, which pretty much exactly matches your "install_options" > functionality. Why can't you grab this example and edit vendor -> > install_options for the yum provider? > > http://groups.google.com/group/puppet-users/browse_thread/thread/234e84e569a40f61?hl=en# Those are not *first class* parameters, they are second-class parameters. `install_options` takes a hash or array containing arbitrary values, which means that: 1. Invalid options are not detected *unless every provider implements that detection*. - that means, no *typo* detection for users - late detection of invalid content (eg: array for single value parameter) 2. The rest of the infrastructure has *no* visibility of those options - the dashboard can't understand their structure, options, or visibility - the reports can't meaningfully capture that information - `puppet resource` can't report these provider-specific parameters - there is no automatic documentation of these parameters - there is no API introspection of those parameters Providing a single slot that can contain an arbitrary, complex data structure that is passed uninspected to the provider is simple in one sense, but complex in another - in that it abandons any pretence of understanding the structure of parameters to types and providers. (Except, in most of the suggested implementations, it does that dishonestly: it abandons it for some-but-not-all of the places that we handle parameters.) ---------------------------------------- Feature #4113: Allow provider-specific options as a first class part of the RAL model. https://projects.puppetlabs.com/issues/4113#change-77667 Author: Oliver Hookins Status: Accepted Priority: Normal Assignee: Category: Target version: 3.x Affected Puppet version: 0.25.5 Keywords: Branch: http://groups.google.com/group/puppet-users/browse_thread/thread/2ef615fc42225d99?pli=1 Our requirement is more or less the same as in the linked thread, we need to use a proxy to install gems but for a variety of reasons can't set a global proxy on the machines. Thus some way of passing options to gem is necessary. (Nigel) - We should do this consistently across providers, perhaps combining with the "preseed" functionality of apt/dpkg. Rather than doing this as a generic "pass unstructured data" hack, we should resolve this by allowing provider-specific parameters to be first class elements in declarations: <pre> package { example: provider => something, something_specific_parameter => value } </pre> That should cover more than just packages - extending to all types. Requiring the provider to be explicitly specified is preferable to allowing it to be inferred when non-type parameters or properties are present. It is unclear if both properties and parameters should be supported, or if only parameters should be allowed. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
