----- Original Message ----- > From: "gareth rushgrove" <gar...@morethanseven.net> > To: "puppet-dev" <puppet-dev@googlegroups.com> > Sent: Tuesday, 10 May, 2016 10:52:53 > Subject: Re: [Puppet-dev] metaparam question
> On 9 May 2016 at 13:58, R.I.Pienaar <r...@devco.net> wrote: >> >> >> ----- Original Message ----- >>> From: "gareth rushgrove" <gar...@morethanseven.net> >>> To: "puppet-dev" <puppet-dev@googlegroups.com> >>> Sent: Monday, 9 May, 2016 14:55:12 >>> Subject: Re: [Puppet-dev] metaparam question >> >>> On 1 May 2016 at 19:33, R.I.Pienaar <r...@devco.net> wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "R. I. Pienaar" <r...@devco.net> >>>>> To: "puppet-dev" <puppet-dev@googlegroups.com> >>>>> Sent: Thursday, 3 March, 2016 09:58:42 >>>>> Subject: Re: [Puppet-dev] metaparam question >>>> >>>>> ----- Original Message ----- >>>>>> From: "Erik Dalén" <erik.gustav.da...@gmail.com> >>>>>> To: "puppet-dev" <puppet-dev@googlegroups.com> >>>>>> Sent: Thursday, 3 March, 2016 09:43:30 >>>>>> Subject: Re: [Puppet-dev] metaparam question >>>>> >>>>>> On Fri, 5 Feb 2016 at 00:35 Kylo Ginsberg <k...@puppetlabs.com> wrote: >>>>>> >>>>>>> On Wed, Feb 3, 2016 at 7:47 AM, R.I.Pienaar <r...@devco.net> 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. yeah, so I stuck the post in there because this is different from say the existing validate_cmd option on the file resource that puts the file in a temporary location, checks it and then if that pass it puts it in the final destination. The 'post' is to communicate that this happens after puppet had done all it will do to make the resource in the desired state. File also have a validate_replacement that might be useful here. Trying to make it clear a possible what this does, anyway, terrible at naming things as always :) Chef had a minitest integration that let you stick some validation logic in a cookbook to be run post resources and that was very helpful so I've wanted something like this since I first saw that probably 6 o 7 years ago. The idea that we can run these things out of band by monitoring systems at a completely different time cadence than puppet runs which are very heavy is interesting because it takes us a lot closer to zero config monitoring state than ever before and CM systems are quite uniquely positioned to do that, be it cross node or single node or whatever. With metrics and a feedback mechanism back to orchastration tools this is can become a very powerful tool for doing dynamic node placement or auto scaling etc. I am not sure but I hope we can treat the catalog as a stable integration point to puppet so that external query tools to extract this kind of information can be stable, if not I suppose this would be worth discussing too -- 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/2066541993.117350.1462873213584.JavaMail.zimbra%40devco.net. For more options, visit https://groups.google.com/d/optout.
