On Mon, Jul 21, 2014 at 1:00 PM, Andy Parker <a...@puppetlabs.com> wrote:
> On Mon, Jul 21, 2014 at 10:37 AM, Nan Liu <nan....@gmail.com> wrote: > >> I'm using puppet-system module and the usage of the schedule >> metaparameter is generating a large amount of warnings similar to the one >> below (about 30 lines): >> >> Warning: schedule is a metaparam; this value will inherit to all >> contained resources in the system::sysconfig::puppet definition >> >> > I'm actually surprised that is a warning and not a flat out error. The > effect that it has is that now a user can't have a list of metaparams in > their head when reading code and know when a parameter is *truly* one and > and when it isn't. > Not really my module: https://github.com/erwbgy/puppet-system, but I think the way module was written it should work because the value is passed as a default for create_resources. Here's an example: https://github.com/erwbgy/puppet-system/blob/master/manifests/packages.pp In this case, I think the behavior makes sense and I would like to exclude >> this from appearing since the noise is masking more useful warnings. I >> don't believe there's an option to disable warnings and in this case I >> really want to just ignore it for this one module and not globally disable >> it everywhere. I haven't found a good solution than monkey patching puppet >> type: >> >> alias_method :orig_warn_if_metaparam, :warn_if_metaparam >> >> def warn_if_metaparam(param, default) >> if self.name =~ /^system/ and param=='schedule' >> return >> else >> orig_warn_if_metaparam(param, default) >> end >> end >> >> Seems like there are other messages in puppet that people find annoying >> than helpful: >> https://github.com/boxen/puppet-boxen/blob/master/lib/ >> puppet/provider/package/hax.rb >> >> This seems pretty hideous, and I'm wondering if there are more sensible >> way to solve this. >> >> > We recently added "disable_warnings" and right now it can only deal with > deprecations, but the design was such that it can affect other warnings as > well. It would, however, be a global setting and I think it should stay as > such. > > I think what I'm trying to say is that, in this case, you really should > rename that parameter for the sake of your users :) > The purpose of this parameter is to behave exactly the same as puppet metaparameter schedule: https://github.com/erwbgy/puppet-system#usage It's rather unfortunate, but certainly doable to relabel all these parameter with another name on my fork. Similar to the discussion of collect resources realize + override, I wish the metaparameters weren't magically passed to the resources, and we could choose to use them and pass the behavior on as needed. Nan -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CACqVBqDLZ3HRcPZ_TUmfS7Q9EDN6-h6%3DqX2hfsQtB5U-Wiht3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
