FAQ
Puppet seems geared towards managing hosts where changes can be pushed
atomically. What I mean is, suppose some class required another class...
an application requires a file to exist. You can actually make that file
first on the target host and then install or change the application.

I'm trying to deal with a host that only permits changes in batches.
Effectively all the changes are put into a "window" and then the window is
committed. Something on the backend (separate from puppet) in the host
handles the ordering of the individual elements.

What is the best way of dealing with this in Puppet? We don't want to
expose the final "commit" to the person building manifests for hosts.. we
want to reuse those abstractions on other platforms that don't use a change
window.

Obviously, we're going to build a provider. We can't embed a commit into
every atomic element (committing a window, no matter how big or small takes
too long), we just want to ensure that whenever configuration state is
modified for this host, all changes are put into the window and then a
single final commit is executed..

I'm probably not the first to ask, but I spent some hours looking around in
books, internet, etc... didn't really grok how to do this. If I missed
something, please provide a pointer or link...

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Zuqkz_u-T-cJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Nan Liu at Nov 1, 2012 at 3:38 am

    On Wed, Oct 31, 2012 at 9:19 AM, Derick Winkworth wrote:
    Puppet seems geared towards managing hosts where changes can be pushed
    atomically. What I mean is, suppose some class required another class...
    an application requires a file to exist. You can actually make that file
    first on the target host and then install or change the application.

    I'm trying to deal with a host that only permits changes in batches.
    Effectively all the changes are put into a "window" and then the window is
    committed. Something on the backend (separate from puppet) in the host
    handles the ordering of the individual elements.

    What is the best way of dealing with this in Puppet? We don't want to
    expose the final "commit" to the person building manifests for hosts.. we
    want to reuse those abstractions on other platforms that don't use a change
    window.
    Just build resources to queue the changes and not flush it. This will
    cause the resource output to be a bit misleading, since you are
    queueing the change and the system hasn't updated yet. As long this
    doesn't create unintended side effect you should be ok.
    Obviously, we're going to build a provider. We can't embed a commit into
    every atomic element (committing a window, no matter how big or small takes
    too long), we just want to ensure that whenever configuration state is
    modified for this host, all changes are put into the window and then a
    single final commit is executed..
    If you are building resources, you can implement flush method per
    resource. I'm not aware hooks for doing something at the end for a
    resources type.

    I'm assuming you are looking at something like commit, and the
    sensible thing is make commit a resource and have it autorequire all
    other resource type so it executes last.

    Thanks,

    Nan

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Nov 1, 2012 at 2:18 pm

    On Wednesday, October 31, 2012 11:19:20 AM UTC-5, Derick Winkworth wrote:
    Puppet seems geared towards managing hosts where changes can be pushed
    atomically. What I mean is, suppose some class required another class...
    an application requires a file to exist. You can actually make that file
    first on the target host and then install or change the application.


    Yes.

    I'm trying to deal with a host that only permits changes in batches.
    Effectively all the changes are put into a "window" and then the window is
    committed. Something on the backend (separate from puppet) in the host
    handles the ordering of the individual elements.

    That sounds unusual. How much of it is policy, and how much is software?
    Is a "window" a program (e.g. some kind of script) or data (e.g. a
    recursive diff)? How is a "window" assembled if you're making changes by
    hand?


    What is the best way of dealing with this in Puppet? We don't want to
    expose the final "commit" to the person building manifests for hosts.. we
    want to reuse those abstractions on other platforms that don't use a change
    window.

    If you want Puppet to be able to trigger that commit at all then the only
    way I can think of to avoid exposing it in some form to manifest authors is
    to hack the agent.


    Obviously, we're going to build a provider. We can't embed a commit into
    every atomic element (committing a window, no matter how big or small takes
    too long), we just want to ensure that whenever configuration state is
    modified for this host, all changes are put into the window and then a
    single final commit is executed..

    Then obviously you're *not* going to build a provider. Or at least not *one
    * provider, unless it's for a new native resource type that you are also
    going to build. Providers are specific to particular resource types.

    I'm probably not the first to ask, but I spent some hours looking around
    in books, internet, etc... didn't really grok how to do this. If I missed
    something, please provide a pointer or link...
    Actually, you are the first I remember ever asking a question along these
    lines around here. I've never heard of a system such as you describe;
    perhaps it's less common than you suppose.

    Anyway, it's difficult to give useful advice without understanding any
    details of what needs to or does happen on the target node.

    If all you need to do is bracket normal resource-management actions with
    transaction-start and transaction-end commands, then there are several ways
    to approach it via Puppet. The first thing to focus on in that case is
    probably what it means to avoid exposing the "commit" action to the
    manifest author.

    If you need something different, then now would be a good time to explain
    it more fully.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/vnbmSq107rcJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedOct 31, '12 at 5:23p
activeNov 1, '12 at 2:18p
posts3
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase