Puppet users - Feb 2013 - Alternatives to attempting self-modifying puppet code....

The title pretty much sums it up.

I''ve got a situation where I need to have puppet enforce a given state
most
of the time, then when a certain flag is present it needs to use a 
different state - but only until a certain amount of time has passed, at 
which point it needs to go back to the normal state of things.

I''ve got some ideas on how I can make this happen, but I am looking for
some more sane alternatives.

I have setup a question with details 
here:
https://ask.puppetlabs.com/question/447/best-way-to-deal-with-temporary-state-changes/

But the short version is I don''t want to get up at 0200 to stop
services in
prod for developers when they need to update database tables, and I
don''t
want to have to remember to revoke their access (controlled via puppetized 
likewise config) the morning after the changes.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Monday, February 11, 2013 4:30:16 PM UTC-6, llowder
wrote:
>
> The title pretty much sums it up.
>
> I''ve got a situation where I need to have puppet enforce a given
state
> most of the time, then when a certain flag is present it needs to use a 
> different state - but only until a certain amount of time has passed, at 
> which point it needs to go back to the normal state of things.
>
> I''ve got some ideas on how I can make this happen, but I am
looking for
> some more sane alternatives.
>
> I have setup a question with details here: 
>
https://ask.puppetlabs.com/question/447/best-way-to-deal-with-temporary-state-changes/
>
> But the short version is I don''t want to get up at 0200 to stop
services
> in prod for developers when they need to update database tables, and I 
> don''t want to have to remember to revoke their access (controlled
via
> puppetized likewise config) the morning after the changes.
>
>
How about instead of using a simple flag in your hiera data, you use a 
timestamp (in some form) of when the permissive access is supposed to 
expire?  When choosing which config to use, the master then just compares 
the timestamp to its system date/time.  I''d write the comparison as a 
custom function, but you could do it in an inline template for proof of 
concept.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Tuesday, February 12, 2013 8:28:18 AM UTC-6, jcbollinger
wrote:
>
>
>
> On Monday, February 11, 2013 4:30:16 PM UTC-6, llowder wrote:
>>
>> The title pretty much sums it up.
>>
>> I''ve got a situation where I need to have puppet enforce a
given state
>> most of the time, then when a certain flag is present it needs to use a
>> different state - but only until a certain amount of time has passed,
at
>> which point it needs to go back to the normal state of things.
>>
>> I''ve got some ideas on how I can make this happen, but I am
looking for
>> some more sane alternatives.
>>
>> I have setup a question with details here: 
>>
https://ask.puppetlabs.com/question/447/best-way-to-deal-with-temporary-state-changes/
>>
>> But the short version is I don''t want to get up at 0200 to
stop services
>> in prod for developers when they need to update database tables, and I 
>> don''t want to have to remember to revoke their access
(controlled via
>> puppetized likewise config) the morning after the changes.
>>
>>
>
> How about instead of using a simple flag in your hiera data, you use a 
> timestamp (in some form) of when the permissive access is supposed to 
> expire?  When choosing which config to use, the master then just compares 
> the timestamp to its system date/time.  I''d write the comparison
as a
> custom function, but you could do it in an inline template for proof of 
> concept.
>
>
I did wind up using a custom function (first time writing one, was 
relatively painless), but I think on home time rather than work time I will 
do a self-modifying solution just as a proof of concept, and to serve as an 
example of what NOT to do.

 
>
> John
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.