-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This hits close to home with something that I would love to see added to
the puppetmaster but haven't quite figured out how to describe until
recently.
I recently realized that, for a given environment, what you actually
have is a massive parallel program running across various nodes.
Therefore, what I would like in the puppetmaster is a set of
stored-state named semaphores.
They would work as follows:
Semaphore: DB=0 on the puppetmaster
node web_server {
if semaphore('semaphore_db') > 0 {
include "foo"
include "bar"
}
}
node db_server {
include "db"
}
class db {
service { "some_db":
ensure => 'running',
require => Exec['set_me_up']
}
exec { 'set_me_up':
command => 'do stuff',
notify => semaphore('semaphore_db', '>=', '1')
}
}
So, what this would do, is to set the semaphore $semaphore_db to 1 only
if the exec properly executes (which means that the DB got set up
correctly) and then would only set it to 1 if it was not already >= 1 so
that multi-state processes can be handled.
Then, once the semaphore has been set, web_server would include what it
needed to properly function.
Note that this is not a locking process, the normal run of puppet would
ensue and the state change would only be noticed on the next run.
This does lag things out over a few runs of puppet, but also (I think)
keeps the entire thing running the 'puppet way' by essentially setting a
cross-system state fact.
I figured that the semaphore call would be an TLS REST call back to the
master, or a separate lookup process if you wanted to offload the work
to a different system.
Thanks,
Trevor
On 02/04/2010 03:42 PM, Michael DeHaan wrote:
> On Thu, Feb 4, 2010 at 9:58 AM, jcbollinger <john.bollin...@stjude.org> wrote:
>>
>>
>> On Feb 3, 3:08 pm, Michael DeHaan <mich...@reductivelabs.com> wrote:
>>> Actually I think it can be done by leveraging an improved storeconfigs and
>>> the existing language.
>>
>> I was wondering whether storeconfigs would come up. The problem I see
>> with that is storeconfigs, as I understand them, record the managed
>> resource states each host *should* have, not necessarily those each
>> one *does* have. What happens to my multinode deployment if at some
>> point in the middle, Puppet fails to apply a necessary resource state?
>
> If Puppet fails applying a state, it should record the current state,
> not the once and future state.
>
> I'll dig into the schema of what it does now, but don't limit your
> thinking based on what storeconfigs currently does or is,
> think about what it can be.
>
>
>
>> Absolutely so, and that connects back to your earlier comments about
>> message buses. Messaging is the lifeblood of any kind of
>> orchestration technology, but there are a variety of message exchange
>> patterns, message implementations, and messaging options, many
>> combinations of which are viable. Some could reasonably be
>> characterized as "push", but many others couldn't.
>
>
> This is an software architecture statement, and architecture is
> independent of execution and concepts.
>
> Long term, I expect to see messaging will happen and can then play a
> much wider role mainly for offline delivery implications
> and routing. Though much can be hinged on present workings, whether
> RESTful or RPCy (which, aren't all that different regardless).
>
> However, first, small steps.
>
>>
>> Any way around, there is a class of messages needed for this that
>> Puppet does not currently have: messages from clients advertising the
>> individual or collective state of their managed resources. The
>> absolute simplest form would be a reply to the Puppetmaster indicating
>> whether a catalog was successfully applied, but finer-grained state
>> messages would be much more flexible. These would address the problem
>> of discrepancy between supposed and actual state.
>
> Eventing and reporting, and an evolved storeconfigs concept are
> something we're looking at, for sure.
>
> Stay tuned, and of course, if you have time, patches are very much welcome.
>
- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvaug...@onyxpoint.com
phone: 410-541-ONYX (6699)
- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAktr9CYACgkQyWMIJmxwHpR1kwCgvsOCN3x30q/INfSn2yQ0DTSR
aOwAnjztorRfAVsdCGk9UdyCxDZy3Ok6
=9cF1
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
