On May 14, 2015, at 4:00 PM, Erik Dalén <[email protected]> wrote: > > > > On Thu, 14 May 2015 at 21:45 Trevor Vaughan <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > > > > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> >> -- >> 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 [email protected] >> <mailto:puppet-dev%[email protected]>. >> 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> >> [email protected] <mailto:[email protected]> >> >> -- This account not approved for unencrypted proprietary information -- >> >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 <tel:%28410%29%20541-6699> >> [email protected] <mailto:[email protected]> >> >> -- 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 [email protected] >> <mailto:[email protected]>. >> 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 [email protected] > <mailto:[email protected]>. > 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 > [email protected] <mailto:[email protected]> > > -- 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 [email protected] > <mailto:[email protected]>. > 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 [email protected] > <mailto:[email protected]>. > 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 [email protected]. 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.
