Hey! Do you have a link to that presentation? For a Java spin lock, wouldn't it go something like:
* First try -> Wait until timeout * Timeout -> Drop file * Second try -> Notice and remove file * Try again * etc... Trevor On Thu, May 14, 2015 at 3:33 PM, Spencer Krum <[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] > > > > 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]. > 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 > [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 > <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. > > > > -- > 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 > <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. > -- 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%2BFoUGwDY6dyCUibJyREvVk4ezid6td%3DBcvpGLmVkQb%3DtwzQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
