On Thu, May 14, 2015 at 12:54 PM, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:
> - 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? > sorry if this is a little bit of hi-jacking. and please feel free to tldr :) I've been experimenting with lots of variations, in all variations, it relies on externally available service profiles to include puppet for registering their services on consul along with service checks. For the consuming (or dependent services), I experimented with 3 different models. 1. (DID NOT WORK) fail to compile catalog if external resources are not ready or available. This approach did not work for my applications b/c it deadlocks if you have any circular cross host dependencies. It also doesn;t allow you to pre-compile a version of a catalog before all it's dependencies are ready (which I use to pre-install packages to optimize overall build times) 2. (MIGRATING AWAY FROM) Block until services are discoverable via DNS (or through consul's service apis). This model is very similar to the model approached in this path, and it worked, but it was less than ideal for a few reasons: - There is no way to specify the blocking resources as nice. They wind up blocking lots of things that they don't need to if they exist in a place in the graph where order it ambiguous. - Don't handle catastrophic failure well. In cases where everything blows up, Puppet might be able to remediate to a working state, but it winds up being blocked on these resources. This is very frustrating and is the main reason that I wound up moving away from this model. 3. Check state during compile, pass data to a special resource that fails subgraphs. Puppet doesn't really support passing state info between resources at run-time (this seems like the biggest difference between Puppet/Chef). For this reason, we wanted to check state during compile time where that state can be forwarded. We created a specify resource called runtime_fail ( https://github.com/JioCloud/puppet-orchestration_utils/blob/master/lib/puppet/type/runtime_fail.rb) that does nothing except take this data and then fail a subgraph. the typical example is something like: class someclass( $external_service = values(service_discovery_consul('some.dns.address')), ) { # fail if service has not reached quorum if size($external_service) != 3 { $fail = true } else { $fail = false } runtime_fail { 'quorum not reached for external service': fail => $fail } service {'local_service': require => Runtime_fail['quorum not reached for external service'] } } > > 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 <bod...@gmail.com> 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 >>> ni...@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/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 > 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%2BFoVsS%3D_2S1fSK-CZPqp1%3D%3Dx87H7txdURErH%2BBTZgabQ_JQ%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVsS%3D_2S1fSK-CZPqp1%3D%3Dx87H7txdURErH%2BBTZgabQ_JQ%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/CA%2B0t2LzEYZg7uq%2B9K1k%2B2WDs4Bpv1jzbq1njGUF_kpO4eqPhnA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
