On May 14, 2015, at 12:11 PM, Spencer Krum <n...@spencerkrum.com> 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 puppet-dev+unsubscr...@googlegroups.com. 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.
