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.

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 puppet-dev+unsubscr...@googlegroups.com.
> 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 puppet-dev+unsubscr...@googlegroups.com.
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.

Reply via email to