Thanks everyone for your feedback. It sounds like this is a popular idea, and one that leads into further discussion.
I've created https://github.com/puppet-community/puppet-healthcheck and asked spredzy to submit the PR against that repo. Cheers, Spencer -- Spencer Krum [email protected] On Fri, May 15, 2015, at 03:52 PM, Luke Kanies wrote: > On May 14, 2015, at 12: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? > > (Sorry, coming late to the thread.) > > I think this is a great idea. > > I built something similar a long time ago: > > https://github.com/puppetlabs/puppetlabs-remote_resource/blob/master/ext/example.pp > > I agree it should be independent, at least for now, to support faster > evolution and because I like small things. :) > > However… > > This is something we’re working on a ton internally, for related but > different reasons. Nothing is in a state that’s worth sharing, > unfortunately, because this is just one part of a much larger project and > we can’t easily share any of it until we can share all of it (because > it’s very confusing in its current state, among other reasons). > > Basically, we want to build a special kind of resource for exactly this. > All resources of this special type would share some values, like interval > and timeout, and then each resource type would provide the parameters for > things like IP address, port, etc. > > We want to go quite a bit past just checking IP and port, though. > > I want a base provider that can just check network status, but why not a > provider that can check whether a database is all set up, and a user can > connect with a specific password? > > Or why not something that validates that a filesystem is available? No > network information, just validate that a file is present, or something > similar. These often take a while to actually work. > > Or even more, why not confirm that a configuration file is valid? > Wouldn’t you love something that would roll back the sudoers file if you > managed to deploy a broken one? > > In other words, this should be a generic framework, with generic support > from Puppet, and we should provide as much power to the framework as > possible. > > We’re really only focused on the simplest form of health checks at this > point, but because we’re explicitly expecting to make some changes to > core Puppet to make some of it work, we likely won’t be able to make the > whole thing external. > > We’re basically at the “plan to build” phase right now, without full > designs in place. > > David Lutterkort is one of the eng leads, and Ryan Coleman is the product > manager. > > And I’m off to China for a week in 12 hours, so I’ll be off the grid for > the next week, and thus can’t elaborate. :/ > > And, in regards to Trevor’s rant, and pointing to the old ticket, yeah, > it’s exactly that stuff (plus a lot more) that’s led us to this. We’re > just finally getting to invest in it. :) > > > — > 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/651C9A29-8133-4E1A-B14E-8493B203E091%40puppetlabs.com. > 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/1432120487.1881432.273620145.58969296%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
