Hmm....what about a concept of deferred actions? I.e. Try this resource, can't do it, shove it (and it's dependencies) to the bottom of the stack and do everything else, then come back to it.
You could even technically have a method for simply backgrounding that entire resource chain. This sort of sends me down an idea that I had that I'd like to be able to apply, by reference, a puppet resource chain from an excerpt of the catalog. For instance: As the catalog runs, I would like to have each catalog collection fragmented into a mini catalog that I could use to apply with other utilities. Since it's a DAG, this should be relatively easy but you could potentially incur a lot of I/O overhead. BUT, you could have something like the Puppet deferred action daemon (Puppet-DAD) that would pick those items up after the main Puppet run and execute them, sending a report back after each fragment. *sigh*....and now more from Puppet 22. Thanks, Trevor On Thu, May 14, 2015 at 3:33 PM, Spencer Krum <n...@spencerkrum.com> wrote: > Trevor, > > I agree that if you take it to its logical conclusion you end up with > semaphores stored in consul and a handful of Puppet resources to interact > with them. Dan Bode presented on exactly this (and what doesn't work well > about it) at the PDX Puppet Users group last month. > > I think though that from a practical standpoint, these resources as > written have value. Simply waiting for some java process to start before > you do follow-on actions is a common task. And looking to the future I'd > like to see them live in their own module so we can evolve them without > symver constraints. > > -- > Spencer Krum > n...@spencerkrum.com > > > > On Thu, May 14, 2015, at 12:29 PM, Trevor Vaughan wrote: > > Ugh, sorry all, didn't mean to make that so rant-ish. > > Anyway, it would seem that you would not want to hold up a catalog > compilation or application for this. Instead, you would want to register > the check with a service that could drop a queriable entity that could be > used by Puppet for making decisions about the compilation and/or > application of the catalog. > > PuppetDB may be the ideal place to host this but it could also be a > stand-alone, authenticated, service. > > Obviously, nodes should only obtain their own data unless explicitly > shared between a node group. > > In terms of naming, I would probably call it network_service_status or > some such. > > Thanks, > > Trevor > > On Thu, May 14, 2015 at 3:24 PM, Trevor Vaughan <tvaug...@onyxpoint.com> > wrote: > > I'd like to counter this limited use case with my rant about semaphores > from five years ago: > http://comments.gmane.org/gmane.comp.sysutils.puppet.devel/13039. > > Followed by the conversation from two years ago. > https://projects.puppetlabs.com/issues/16187 > > What you want is cross-node synchronization and synchronization storage > state. > > You can sort of do this with exported resources, but it's VERY clumsy. > > I know that it's a long shot, but I figure that I'll resurrect it as > appropriate every couple of years ;-). > > Other than that, why not call it 'haproxy'. > > Trevor > > > On Thu, May 14, 2015 at 3:11 PM, Spencer Krum <n...@spencerkrum.com> > wrote: > > Hi Folks, > > There is currently a PR against stdlib that I am writing to you today > about: https://github.com/puppetlabs/puppetlabs-stdlib/pull/444 > Thanks to Spredzy for making this PR. > > This is tracked in jira: > https://tickets.puppetlabs.com/browse/MODULES-1982 > > This pattern has poked up a few different places. As the PR says, it has > shown up in the monogodb module and the puppetdb module. I know that > Michael Chapman added something like this to his OpenStack things and > Dan Bode as well. > > At the modules triage today we had the following reactions (please reply > if there is something you said I didn't get): > > * This is a new pattern > * Having it in stdlib means we can't iterate on it quickly > * This is a library thing, and should be a library > * Once standardized, puppetdb and other modules could be retrofitted to > use it > * This will probably change frequently as people use it and explore what > it should/can do > > We had the idea that rather than landing this in puppet-stdlib, that we > could create a module in puppet-community to hold this and other > validation/health check resources. > > We had some ideas on the name: > > puppet-healthcheck > puppet-validation > puppet-external_validate. > > It's worth noting that these are primitives for building multi-node > orchestration with Puppet. > > What do you think? Do you use these patterns? Would you? What would you > want from your library? > > Thanks, > Spencer > > > -- > Spencer Krum > n...@spencerkrum.com > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/1431630674.2625129.268922745.5AA0382C%40webmail.messagingengine.com > . > For more options, visit https://groups.google.com/d/optout. > > > > > -- > > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaug...@onyxpoint.com > > -- This account not approved for unencrypted proprietary information -- > > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaug...@onyxpoint.com > > -- This account not approved for unencrypted proprietary information -- > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXvKm6u%2BbJoz2jUwttsiUBKhLLWphvGPzOkG3--j%3DK9Pw%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXvKm6u%2BbJoz2jUwttsiUBKhLLWphvGPzOkG3--j%3DK9Pw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/1431631985.2629204.269015401.157E8B43%40webmail.messagingengine.com > <https://groups.google.com/d/msgid/puppet-dev/1431631985.2629204.269015401.157E8B43%40webmail.messagingengine.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWpRpn6zj-yD9Qdqvvj5GFrGDo8biAFX3q_vF9xYD7rqw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
