[chef] Re: Thoughts on service monitoring...


Chronological Thread 
  • From: Jeffrey Hulten < >
  • To:
  • Subject: [chef] Re: Thoughts on service monitoring...
  • Date: Mon, 26 Nov 2012 10:01:44 -0800


On Nov 25, 2012, at 4:20 PM, Peter Donald wrote:

> Hi,
> 
> On Thu, Nov 22, 2012 at 5:37 AM, Jeffrey Hulten 
> < >
>  wrote:
> There are multiple ways to keep a service up from runit to bluepill, but 
> everyone uses something different. I don't know a lot about these tools, 
> would there be a way to make a generalized resource or an extension to the 
> service resource that managed this?
> 
> I suspect if you were to take an opinionated stance on services then it 
> would be possible to do this. One of the main reasons I would like this is 
> to make some of the cookbooks I write more compatible with RHEL systems - 
> right now, most of the cookbooks we create use upstart which is one of the 
> few things that stop them being RHEL compatible.
> 
> In the next month we plan on looking on replacing upstart usage with runit 
> (or something else?) and I had it on my list to investigate [1] to see if 
> that could be integrated into chef. Hearsay says they have already done 
> most of the hardwork.
> 
> [1] https://github.com/ddollar/foreman
> 
> -- 
> Cheers,
> 
> Peter Donald

A lot of my thinking is based on our discussions at the community summit. 
Cookbook dependencies are become more important as we use tools like 
Berkshelf, but many cookbooks depend on things that are not required in every 
case.

For instance the nginx cookbook depends on both runit and bluepill. You are 
not going to use both at the same time, but the tools don't know that.

If, however, we had a way to tell the service resource to use runit or 
bluepill based on an attribute and defaulted to the standard OS method 
otherwise then we could eliminate the dependency on the tool we aren't using.

--
Jeffrey Hulten
Principal Consultant at Automated Labs, LLC

  206-853-5216
Skype: jeffhulten

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail




Archive powered by MHonArc 2.6.16.

§