Socket control for chef-client


#1

While I’m at it, have you had more thoughts about the idea behind
https://github.com/grantr/chef/commits/socket ?

It provides a way to trigger single-recipe runs.


Laurent


#2

On Mar 5, 2012, at 5:33 AM, laurent+opscode@u-picardie.fr wrote:

While I’m at it, have you had more thoughts about the idea behind
https://github.com/grantr/chef/commits/socket ?

It provides a way to trigger single-recipe runs.

Looks like it does a great deal more than that, it’s basically a first pass at an IPC API. You could build on this to push in any config change you wanted (node attributes, log level, etc). Very cool indeed.

My question is: don’t you want those changes written down somewhere? What’s the added value in applying a run list that isn’t from a chef server or solo repository? What extra good does it have over updating the centralized run list and just running chef?


http://josephholsten.com


#3

Joseph Holsten joseph@josephholsten.com writes:

On Mar 5, 2012, at 5:33 AM, laurent+opscode@u-picardie.fr wrote:

While I’m at it, have you had more thoughts about the idea behind
https://github.com/grantr/chef/commits/socket ?

It provides a way to trigger single-recipe runs.

Looks like it does a great deal more than that, it’s basically a
first pass at an IPC API. You could build on this to push in any
config change you wanted (node attributes, log level, etc). Very
cool indeed.

My question is: don’t you want those changes written down somewhere?
What’s the added value in applying a run list that isn’t from a chef
server or solo repository? What extra good does it have over
updating the centralized run list and just running chef?

In my case i just want to be able to run one recipe instead of the
main huge centralised run_list.

Again, I could work around this with a special cookbook that would
alter the run_list.
For example the special cookbook would read a json file (with either
recipes to run, or recipes to skip), alter chef-client run_list
accordingly and remove the json file eventually.


Laurent


#4

(reposting again from the right email addy I think)

What exactly is the concern here? If you don’t trust your client runs
to not undo something then you’ve got a much bigger problem.

If the concern is time, then better effort is spent optimizing the cookbooks.

Please also consider something like this:

If you really need to ensure that something is a one time thing, add
it to the runlist for a run and make sure it cleans itself up
afterwards. You can even use the ‘oneshot’ cookbook that Matt Ray
wrote for something more data driven.

On Mon, Mar 5, 2012 at 11:34 AM, laurent+opscode@u-picardie.fr wrote:

Joseph Holsten joseph@josephholsten.com writes:

On Mar 5, 2012, at 5:33 AM, laurent+opscode@u-picardie.fr wrote:

While I’m at it, have you had more thoughts about the idea behind
https://github.com/grantr/chef/commits/socket ?

It provides a way to trigger single-recipe runs.

Looks like it does a great deal more than that, it’s basically a
first pass at an IPC API. You could build on this to push in any
config change you wanted (node attributes, log level, etc). Very
cool indeed.

My question is: don’t you want those changes written down somewhere?
What’s the added value in applying a run list that isn’t from a chef
server or solo repository? What extra good does it have over
updating the centralized run list and just running chef?

In my case i just want to be able to run one recipe instead of the
main huge centralised run_list.

Again, I could work around this with a special cookbook that would
alter the run_list.
For example the special cookbook would read a json file (with either
recipes to run, or recipes to skip), alter chef-client run_list
accordingly and remove the json file eventually.


Laurent


#5

John Vincent lusis.org+chef-dev@gmail.com writes:

[…]

In my case i just want to be able to run one recipe instead of the
main huge centralised run_list.

Again, I could work around this with a special cookbook that would
alter the run_list.
For example the special cookbook would read a json file (with either
recipes to run, or recipes to skip), alter chef-client run_list
accordingly and remove the json file eventually.

What exactly is the concern here? If you don’t trust your client runs
to not undo something then you’ve got a much bigger problem.

If the concern is time, then better effort is spent optimizing the cookbooks.

concern is time :

  1. about 35sec for 231 up to date resources (including the exec
    "apt-get update")
  2. the 30 min interval

I use something like kill -SIGUSR1 $(</var/run/chef/client.pid) for
point 2. I’ll use the run_list alter trick for point 1.

Please also consider something like this:

https://gist.github.com/1979216

yep, that’s what i was thinking of when talking about a “special
cookbook”

If you really need to ensure that something is a one time thing, add
it to the runlist for a run and make sure it cleans itself up
afterwards. You can even use the ‘oneshot’ cookbook that Matt Ray
wrote for something more data driven.

I’me going to have a look at it, thanks.


Laurent


#6

https://github.com/mattray/mattray-cookbooks/tree/master/one-shot is
the cookbook John mentioned.

Thanks,
Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray

On Mon, Mar 5, 2012 at 11:49 AM, laurent+opscode@u-picardie.fr wrote:

If you really need to ensure that something is a one time thing, add
it to the runlist for a run and make sure it cleans itself up
afterwards. You can even use the ‘oneshot’ cookbook that Matt Ray
wrote for something more data driven.

I’me going to have a look at it, thanks.


#7

The “IPC” aspect would be extremely useful for “push” notifications rather
than “polling” of changes to the cluster. This would enable
notify/subscribe between nodes, not just within a node, correct?

That would let a node trigger immediate converges on another node in a
data-driven manner. For example, I have an Apache reverse proxy that
listens for services that announce that they wish to be made available as
part of a dashboard. It queries all nodes that provide a dashboard widget,
similar to what Infochimp’s Silverware does.

When bringing up the cluster or adding something, I have to manually
trigger the converge on the Apache node, if I understand Chef correctly.
This gives the dashboard widget recipe the opportunity to announce that the
Dashboard provider node needs to reconverge to pick up a new node. See the
Silverware cookbook from Infochimps.

Or am I missing something that Chef already does?

On Mon, Mar 5, 2012 at 10:31 AM, Joseph Holsten joseph@josephholsten.comwrote:

On Mar 5, 2012, at 5:33 AM, laurent+opscode@u-picardie.fr wrote:

While I’m at it, have you had more thoughts about the idea behind
https://github.com/grantr/chef/commits/socket ?

It provides a way to trigger single-recipe runs.

Looks like it does a great deal more than that, it’s basically a first
pass at an IPC API. You could build on this to push in any config change
you wanted (node attributes, log level, etc). Very cool indeed.

My question is: don’t you want those changes written down somewhere?
What’s the added value in applying a run list that isn’t from a chef server
or solo repository? What extra good does it have over updating the
centralized run list and just running chef?


http://josephholsten.com


Jason Wagner
jason@tensorwrench.com


#8

You want 'kill -s USR1 cat /var/run/chef.pid’ or similar to send a USR1 signal to the process and wake it up.


http://josephholsten.com

On Mar 5, 2012, at 5:27 PM, “Wagner, Jason” jason@tensorwrench.com wrote:

The “IPC” aspect would be extremely useful for “push” notifications rather than “polling” of changes to the cluster. This would enable notify/subscribe between nodes, not just within a node, correct?

That would let a node trigger immediate converges on another node in a data-driven manner. For example, I have an Apache reverse proxy that listens for services that announce that they wish to be made available as part of a dashboard. It queries all nodes that provide a dashboard widget, similar to what Infochimp’s Silverware does.

When bringing up the cluster or adding something, I have to manually trigger the converge on the Apache node, if I understand Chef correctly. This gives the dashboard widget recipe the opportunity to announce that the Dashboard provider node needs to reconverge to pick up a new node. See the Silverware cookbook from Infochimps.

Or am I missing something that Chef already does?

On Mon, Mar 5, 2012 at 10:31 AM, Joseph Holsten joseph@josephholsten.com wrote:
On Mar 5, 2012, at 5:33 AM, laurent+opscode@u-picardie.fr wrote:

While I’m at it, have you had more thoughts about the idea behind
https://github.com/grantr/chef/commits/socket ?

It provides a way to trigger single-recipe runs.

Looks like it does a great deal more than that, it’s basically a first pass at an IPC API. You could build on this to push in any config change you wanted (node attributes, log level, etc). Very cool indeed.

My question is: don’t you want those changes written down somewhere? What’s the added value in applying a run list that isn’t from a chef server or solo repository? What extra good does it have over updating the centralized run list and just running chef?


http://josephholsten.com


Jason Wagner
jason@tensorwrench.com