> > - I've also moved away from the model of directly querying to perform the > same actions through a service registration/discovery system (in my case > consul)
Interesting, were you doing these in the providers/on the clients, or at catalog compile time? I was thinking it would be a catalog compile service as opposed to a client side operation to minimize distributed complexity. Thanks, Trevor On Thu, May 14, 2015 at 3:48 PM, Dan Bode <[email protected]> wrote: > > > On Thursday, May 14, 2015 at 12:11:19 PM UTC-7, Spencer Krum 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. > > > FWIW, I've moved away from this pattern for a few reasons: > > - blocking catalog execution lad to lots of issues, the worst of which > I've seen is that recovery of failure states can take forever. I've moved > towards a mode is just failing a subgraph quickly if pre-conditions aren't > met. > - I've also moved away from the model of directly querying to perform the > same actions through a service registration/discovery system (in my case > consul) > > >> >> >> 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] >> > -- > 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/408b8895-bdcd-4eb0-981a-0399f6865d64%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/408b8895-bdcd-4eb0-981a-0399f6865d64%40googlegroups.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 [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]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVsS%3D_2S1fSK-CZPqp1%3D%3Dx87H7txdURErH%2BBTZgabQ_JQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
