On May 14, 2015, at 4:00 PM, Erik Dalén <erik.gustav.da...@gmail.com> wrote: > > > > On Thu, 14 May 2015 at 21:45 Trevor Vaughan <tvaug...@onyxpoint.com > <mailto:tvaug...@onyxpoint.com>> wrote: > 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. > > If puppet would think that the provider is not yet suitable it would do > exactly this AFAIK. Would be interesting to "exploit" that mechanism to defer > the processing of that subgraph instead of just blocking.
It wouldn’t be too hard these days to just support this directly, rather than hacking it with provider suitability. Last I heard, Nick Lewis or Patrick Carlisle were the best to ping about this. You basically just need a simple boolean method that indicates whether a resource is ready, then the system to defer resources that aren’t ready. That patch would surely get accepted. :) FWIW, I think it’s a great idea, and would really help. I do think we should support parallelization, but I think that’s also a harder and less universally desired problem. > 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 > <mailto: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 <mailto: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 >> <mailto: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 >> <http://comments.gmane.org/gmane.comp.sysutils.puppet.devel/13039>. >> >> Followed by the conversation from two years ago. >> https://projects.puppetlabs.com/issues/16187 >> <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 >> <mailto: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 >> <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 >> <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 <mailto: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 >> <mailto:puppet-dev%2bunsubscr...@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 >> >> <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 >> <https://groups.google.com/d/optout>. >> >> >> >> -- >> >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 <tel:%28410%29%20541-6699> >> tvaug...@onyxpoint.com <mailto:tvaug...@onyxpoint.com> >> >> -- This account not approved for unencrypted proprietary information -- >> >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 <tel:%28410%29%20541-6699> >> tvaug...@onyxpoint.com <mailto: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 >> <mailto: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 >> <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 > <mailto: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 > <https://groups.google.com/d/optout>. > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaug...@onyxpoint.com <mailto: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 > <mailto: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 > > <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWpRpn6zj-yD9Qdqvvj5GFrGDo8biAFX3q_vF9xYD7rqw%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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 > <mailto:puppet-dev+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdGLvZEEze4FTpBbuJipbjJ6D2cSSdOd5D9TPyrvze4iA%40mail.gmail.com > > <https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdGLvZEEze4FTpBbuJipbjJ6D2cSSdOd5D9TPyrvze4iA%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. — http://puppetlabs.com/ | http://about.me/lak | @puppetmasterd -- 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/6BF2B7BD-9F02-45BA-BA0C-3D60B0CCBD64%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
