FAQ
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.

Search Discussions

  • Jcbollinger at Feb 12, 2013 at 2:28 pm

    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.
  • Llowder at Feb 12, 2013 at 10:19 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedFeb 11, '13 at 10:30p
activeFeb 12, '13 at 10:19p
posts3
users2
websitepuppetlabs.com

2 users in discussion

Llowder: 2 posts Jcbollinger: 1 post

People

Translate

site design / logo © 2022 Grokbase