On a similar vein to this thread....many years ago (six?) I wanted to
introduce a semaphore-based logic construct into the language itself.
I think, with Puppet 4, it might actually be possible!
Technically, as pointed out by one of the team here, we probably want
Phasers, but I didn't know about that construct at the time :-D.
I was going to try to add support to Puppet Server itself but my Clojure-fu
is weak.
The idea was basically:
if amisafe("key_name") > 4 {
class { 'do puppet stuff': ... }
letsbesafe('key_name', 0)
}
else {
class { 'do other optional puppet stuff': ... }
}
I still think it would be interesting to have and, of course, it would
require a central service to manage these things but it could theoretically
be decentralized (consul, etcd, whatever...) and I think it fits in the
general idea of this conversation.
Thanks,
Trevor
On Mon, May 9, 2016 at 2:58 PM, Trevor Vaughan <[email protected]>
wrote:
> Skipping actions during a noop is the only correct solution.
>
> Any time you check a cross-daemon/node state it is relatively likely that
> you're going to be changing something on the network and/or the local
> system.
>
> In many cases, this will be completely innocuous, but in others, it could
> add messages to a queue, or some other nonsense.
>
> I suppose that, if you wanted to get fancy, you could have yet another
> metaparameter which was an array that would let you specify which checks
> could be run in noop mode defaulting to an empty array.
>
> Trevor
>
> On Mon, May 9, 2016 at 8:58 AM, 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?
>>
>> > * 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?
>>
>> --
>> 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.
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788
>
> -- This account not approved for unencrypted proprietary information --
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
--
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/CANs%2BFoXMUt3%3DOi84nWx2zCxVDp%2BJpfoT39vWf0FmboSnODeHEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
