On 6/3/2010 3:54 AM, Trevor Vaughan wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been following this thread with interest and I think that Donavan
is hitting upon something that I've also been wanting.
However, the way I was looking at it was as a set of atomic, optionally
blocking, semaphores in a set of parallel threads.
If you look at each puppet client as an individual thread and realize
that you need things to happen cross-client that depend on the state of
one or more clients, then you've deconstructed this into a classic
parallel programming application (with all the constituent nonsense).
Interesting perspective! Especially as this allows one to re-use the
existing research to evaluate the pitfalls of such an approach.
Deadlocks can be circumvented by partially aborting transactions (i.e.
failing dependend resources) instead of locking.
Serializability is not really a concern of puppet, since we have
eventual convergence.
A more complex problem in our case would be contention of locks (e.g.
when used for orchestrating a N-out-of-M rollout). I'm thinking of
thundering herd problems or often repeated and aborted transactions.
Best Regards, David
--
dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999
FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
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-dev?hl=en.
