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] 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]> 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 >> <[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 >>> 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 >>> [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][1]. >>> 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[2] [email protected] >> >> -- This account not approved for unencrypted proprietary >> information -- >> > > > > -- > 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%2BFoXvKm6u%2BbJoz2jUwttsiUBKhLLWphvGPzOkG3--j%3DK9Pw%40mail.gmail.com[3]. > For more options, visit https://groups.google.com/d/optout. Links: 1. mailto:puppet-dev%[email protected] 2. tel:%28410%29%20541-6699 3. https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXvKm6u%2BbJoz2jUwttsiUBKhLLWphvGPzOkG3--j%3DK9Pw%40mail.gmail.com?utm_medium=email&utm_source=footer -- 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/1431631985.2629204.269015401.157E8B43%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
