On 9 May 2016 at 13:58, R.I.Pienaar <[email protected]> wrote: > > > ----- Original Message ----- >> From: "gareth rushgrove" <[email protected]> >> To: "puppet-dev" <[email protected]> >> Sent: Monday, 9 May, 2016 14:55:12 >> Subject: Re: [Puppet-dev] metaparam question > >> On 1 May 2016 at 19:33, R.I.Pienaar <[email protected]> wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "R. I. Pienaar" <[email protected]> >>>> To: "puppet-dev" <[email protected]> >>>> Sent: Thursday, 3 March, 2016 09:58:42 >>>> Subject: Re: [Puppet-dev] metaparam question >>> >>>> ----- Original Message ----- >>>>> From: "Erik Dalén" <[email protected]> >>>>> To: "puppet-dev" <[email protected]> >>>>> Sent: Thursday, 3 March, 2016 09:43:30 >>>>> Subject: Re: [Puppet-dev] metaparam question >>>> >>>>> On Fri, 5 Feb 2016 at 00:35 Kylo Ginsberg <[email protected]> wrote: >>>>> >>>>>> On Wed, Feb 3, 2016 at 7:47 AM, R.I.Pienaar <[email protected]> wrote: >>>>>> >>>>>>> hello, >>>>>>> >>>>>>> I would like to add a metaparameter - which I think is easy now via >>>>>>> Type.newmetaparam. >>>>>>> >>>>>> >>>>>> We haven't been thinking of metaparameters as a general purpose extension >>>>>> point. This came up once before that I know of, about a year ago, and >>>>>> there's a little discussion of this in >>>>>> https://tickets.puppetlabs.com/browse/PUP-4281. The conclusion we reached >>>>>> at the time was, more or less, to explore whether the desired change >>>>>> could >>>>>> be accomplished with a puppet function and/or a change to core puppet. >>>>>> >>>>>> >>>>>>> >>>>>>> The thing that I can't seem to find any example of though is how to >>>>>>> make this metaparameter do something on the nodes for all providers >>>>>>> or all types. >>>>>> >>>>>> >>>>>>> Imagine there's a metaparam that might describe how to test a resource >>>>>>> works, something like: >>>>>>> >>>>>>> service{"httpd": validate => "check_http --port 80 -H localhost"} >>>>>>> >>>>>>> I'd then want to have some code that would be run on the agent nodes >>>>>>> for any resource that has this param set. >>>>>>> >>>>>> >>>>>> I don't think something like this exists per se, but 'validate' might be >>>>>> one such example of something worth adding to core puppet. Fwiw, one >>>>>> resource-specific example added not too long ago is the file type's >>>>>> validate_cmd: >>>>>> >>>>>> >>>>>> https://docs.puppetlabs.com/puppet/latest/reference/type.html#file-attribute-validate_cmd >>>>>> . >>>>>> >>>>>> >>>>> Just to clarify, validate_cmd works differently in that it validates the >>>>> new contents before replacing the file. >>>>> I guess the generic validate metaparameter would validate the resource >>>>> after it has been synced. >>>> >>>> yes indeed, subtle but important. thanks >>> >>> Late to follow up on this but I had some time to work on this again, >>> >>> service{"http": >>> ensure => "running", >>> post_validate => "/usr/lib64/nagios/plugins/check_http -H localhost" >>> } >>> >> >> First up, this is great. A few minor comments: >> >> * You explicitly don't trigger the script if it's a noop run or the >> resource failed. That obvious matches your specific usecase but I'm >> wondering if it matches all? > > yeah, as this is just playing around with the idea that choice seemed > the right one without dwelling on it too much - I am not actually sure > what would be right. > > Exec for example has all the unless/onlyif stuff and I dont think those > are ran during a noop either - I think it assumes a value? > > Thinking about it, not running it during noop is the only thing thats > safe, people might not do read only things there - though they really > should. And if its the first run the prereq might not be there? >
My thinking here was that failures are not bad, but informational, in the same way as failures of a unit test are not bad. The script run could be passed the success and the noop and do with those as it will, which avoids the issue of a messier interface. >> * Similar vein, the name post_validate assumes the usage is to >> 'validate' the resource. Given the power of this I can imagine other >> uses too, it might be nicer to have a more generic name? > > validate or verify it works yes, what other uses did you have in mind? I guess reporting or metrics or some sort of registration mechanism. Their are other ways of doing those I realise, but as a light-weight integration point this struck me as interesting. I'd probably stick with validate or verify (ie. without the post_) though if it came to that. I could see modules shipping with a verify directory containing scripts to run to confirm a working system too. G > > -- > 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/933229095.334955.1462798703903.JavaMail.zimbra%40devco.net. > For more options, visit https://groups.google.com/d/optout. -- Gareth Rushgrove @garethr devopsweekly.com morethanseven.net garethrushgrove.com -- 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/CAFi_6yKOXX4J6rz4jqVg%2B4X2fe6HGgz5N3of2OL-KCxCduijtw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
