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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
