Exposing attributes from cookbooks you depend on

Chef Infra (archive)
1

How are people typically exposing the attributes that a cookbook you are depending on may have?

For example, I have a cobbler cookbook. It has some attributes that are required for configuring cobbler - things like DHCP, etc.

Then I have my provserv cookbook that wraps it and does a few other things, specific to our org ( installing some content into cobbler and such ).

The provserv cookbook is what’s included in the nodes runlist. But - you need to make sure those cobbler attributes get set, otherwise cobbler isn’t going to work right.

Do you create the same attributes in the provserv cookbook and then overwrite the cobbler ones? ( ie: since I have a default[‘cobbler’][‘dhcp_start’] attribute, do I make a default[‘provserv’][‘dhcp_start’] attribute that sets the cobbler one? ). Do you depend on the user to figure out that provserv is depending on cobbler and they need to read the cobbler cookbook to see what other attributes need to be configured?

Just curious how others are accomplishing this. Examples would be most appreciated.

Thanks

Steve

2

On 3/19/15 12:51 PM, Hajducko, Steven wrote:

How are people typically exposing the attributes that a cookbook you are depending on may have?

For example, I have a cobbler cookbook. It has some attributes that are required for configuring cobbler - things like DHCP, etc.

Then I have my provserv cookbook that wraps it and does a few other things, specific to our org ( installing some content into cobbler and such ).

The provserv cookbook is what's included in the nodes runlist. But - you need to make sure those cobbler attributes get set, otherwise cobbler isn't going to work right.

Do you create the same attributes in the provserv cookbook and then overwrite the cobbler ones? ( ie: since I have a default['cobbler']['dhcp_start'] attribute, do I make a default['provserv']['dhcp_start'] attribute that sets the cobbler one? ). Do you depend on the user to figure out that provserv is depending on cobbler and they need to read the cobbler cookbook to see what other attributes need to be configured?

Just curious how others are accomplishing this. Examples would be most appreciated.

Thanks

Steve
If proserv is just a wrapper around cobbler then set the cobbler
attribute in the proserve/attributes/default.rb file.

I don't know what proserve is, so if those are logically distinct then
it may make sense to have a third cookbook (probably what you might
consider a 'role' cookbook) which sets attributes for both of those
cookbooks.

If cobbler and proserve always go together for a given role and that's
how you expect they'll always be used, and you're writing all this from
scratch, you could go the other direction and just make a role cookbook
with two recipes/cobbler.rb and recipes/proserve.rb files (and a
default.rb that just include_recipe's both of them) and then set all the
attributes directly on that cookbook's attribute file -- you lose some
flexibility of composition this way, but it reduces your cookbook count,
and if you don't forsee needing the composition then YAGNI.

Its also often better to stop using attributes for everything and setup
LWRPs the way the new httpd and mysql cookbooks are doing. then you
could just have a role cookbook which used proserve and cobbler LWRPs
and hard coded the parameters they were passed. If those values are
unlikely to vary in your infrastructure you don't necessarily need to
expose tweakable attributes for everything (again YAGNI). But, that is
probably more refactoring than you want to do right now.

Those are the options, I suspect the first or second option is the one
you want.

3

Provserv is a wrapper ( and the name is made up ) - it does its own things as well, so it's probably best to call it an application cookbook that's depending on another application cookbook. It's also business specific to us. The cobbler cookbook is meant to, in the end, be shared with the community.

The cobbler attributes that need to be set however, need to be set per environment. We'll have several of the 'provserv' applications running, each in its own environment.

My question was about whether people generally re-namespace these attributes when you have a cookbook you're depending on and you need to expose those configurable attributes to the user.

In our case, we'd be setting all these in a Chef environment. But, do I expose them as:

default["provserv"]["dhcp"]["gateway"] = 1.1.1.1

and in the recipe:

node["cobbler"]["dhcp"]["gateway"] = node["provserv"]["dhcp"]["gateway"]

Or do I just document it via the README that 'Hey, if you use this provserv cookbook, you need to configure these ["cobbler"]["dhcp"] attributes for whatever your environment is".

I'll take a look at the httpd and mysql cookbooks to try and grok what you meant by using LWRP's instead for these configurations.

Thanks.

sh

From: Lamont Granquist lamont@chef.io
Sent: Thursday, March 19, 2015 1:07 PM
To: chef@lists.opscode.com
Cc: Hajducko, Steven
Subject: Re: [chef] Exposing attributes from cookbooks you depend on

On 3/19/15 12:51 PM, Hajducko, Steven wrote:

How are people typically exposing the attributes that a cookbook you are depending on may have?

For example, I have a cobbler cookbook. It has some attributes that are required for configuring cobbler - things like DHCP, etc.

Then I have my provserv cookbook that wraps it and does a few other things, specific to our org ( installing some content into cobbler and such ).

The provserv cookbook is what's included in the nodes runlist. But - you need to make sure those cobbler attributes get set, otherwise cobbler isn't going to work right.

Do you create the same attributes in the provserv cookbook and then overwrite the cobbler ones? ( ie: since I have a default['cobbler']['dhcp_start'] attribute, do I make a default['provserv']['dhcp_start'] attribute that sets the cobbler one? ). Do you depend on the user to figure out that provserv is depending on cobbler and they need to read the cobbler cookbook to see what other attributes need to be configured?

Just curious how others are accomplishing this. Examples would be most appreciated.

Thanks

Steve
If proserv is just a wrapper around cobbler then set the cobbler
attribute in the proserve/attributes/default.rb file.

I don't know what proserve is, so if those are logically distinct then
it may make sense to have a third cookbook (probably what you might
consider a 'role' cookbook) which sets attributes for both of those
cookbooks.

If cobbler and proserve always go together for a given role and that's
how you expect they'll always be used, and you're writing all this from
scratch, you could go the other direction and just make a role cookbook
with two recipes/cobbler.rb and recipes/proserve.rb files (and a
default.rb that just include_recipe's both of them) and then set all the
attributes directly on that cookbook's attribute file -- you lose some
flexibility of composition this way, but it reduces your cookbook count,
and if you don't forsee needing the composition then YAGNI.

Its also often better to stop using attributes for everything and setup
LWRPs the way the new httpd and mysql cookbooks are doing. then you
could just have a role cookbook which used proserve and cobbler LWRPs
and hard coded the parameters they were passed. If those values are
unlikely to vary in your infrastructure you don't necessarily need to
expose tweakable attributes for everything (again YAGNI). But, that is
probably more refactoring than you want to do right now.

Those are the options, I suspect the first or second option is the one
you want.

4

On 3/19/15 1:53 PM, Hajducko, Steven wrote:

Provserv is a wrapper ( and the name is made up ) - it does its own
things as well, so it's probably best to call it an application
cookbook that's depending on another application cookbook. It's also
business specific to us. The cobbler cookbook is meant to, in the
end, be shared with the community.

The cobbler attributes that need to be set however, need to be set per
environment. We'll have several of the 'provserv' applications
running, each in its own environment.

My question was about whether people generally re-namespace these
attributes when you have a cookbook you're depending on and you need
to expose those configurable attributes to the user.

In our case, we'd be setting all these in a Chef environment. But, do
I expose them as:

default["provserv"]["dhcp"]["gateway"] = 1.1.1.1

and in the recipe:

node["cobbler"]["dhcp"]["gateway"] = node["provserv"]["dhcp"]["gateway"]

yeah, don't set that attribute in the recipe.

you probably set it in the recipe because you hit the interpolated
attributes problem in the attributes file.

its better to just use default["cobbler"]["dhcp"]["gateway"] in the
attributes file of the proserv cookbook.

5

My preference on this is to re-namespace the attributes the user is
expected to set. I think of it as the "public interface" of a wrapper
cookbook that is tested and also documented in the README.

Cheers, Torben

On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist lamont@chef.io wrote:

On 3/19/15 1:53 PM, Hajducko, Steven wrote:

Provserv is a wrapper ( and the name is made up ) - it does its own things
as well, so it's probably best to call it an application cookbook that's
depending on another application cookbook. It's also business specific to
us. The cobbler cookbook is meant to, in the end, be shared with the
community.

The cobbler attributes that need to be set however, need to be set per
environment. We'll have several of the 'provserv' applications running,
each in its own environment.

My question was about whether people generally re-namespace these attributes
when you have a cookbook you're depending on and you need to expose those
configurable attributes to the user.

In our case, we'd be setting all these in a Chef environment. But, do I
expose them as:

default["provserv"]["dhcp"]["gateway"] = 1.1.1.1

and in the recipe:

node["cobbler"]["dhcp"]["gateway"] = node["provserv"]["dhcp"]["gateway"]

yeah, don't set that attribute in the recipe.

you probably set it in the recipe because you hit the interpolated
attributes problem in the attributes file.

its better to just use default["cobbler"]["dhcp"]["gateway"] in the
attributes file of the proserv cookbook.

6

That's ideal philosophically, but is probably going to produce bad chef
code. One you've hit the computed attributes issue and worked around it
by moving setting attributes in recipes and exposed yourself to
compile/converge issues and started down the path of probably needing to
use 'lazy' attributes, then I'd rethink the idea of re-namespacing the
attributes.

On 3/20/15 2:09 AM, Torben Knerr wrote:

My preference on this is to re-namespace the attributes the user is
expected to set. I think of it as the "public interface" of a wrapper
cookbook that is tested and also documented in the README.

Cheers, Torben

On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist lamont@chef.io wrote:

On 3/19/15 1:53 PM, Hajducko, Steven wrote:

Provserv is a wrapper ( and the name is made up ) - it does its own things
as well, so it's probably best to call it an application cookbook that's
depending on another application cookbook. It's also business specific to
us. The cobbler cookbook is meant to, in the end, be shared with the
community.

The cobbler attributes that need to be set however, need to be set per
environment. We'll have several of the 'provserv' applications running,
each in its own environment.

My question was about whether people generally re-namespace these attributes
when you have a cookbook you're depending on and you need to expose those
configurable attributes to the user.

In our case, we'd be setting all these in a Chef environment. But, do I
expose them as:

default["provserv"]["dhcp"]["gateway"] = 1.1.1.1

and in the recipe:

node["cobbler"]["dhcp"]["gateway"] = node["provserv"]["dhcp"]["gateway"]

yeah, don't set that attribute in the recipe.

you probably set it in the recipe because you hit the interpolated
attributes problem in the attributes file.

its better to just use default["cobbler"]["dhcp"]["gateway"] in the
attributes file of the proserv cookbook.

7

So I read over the httpd and mysql and saw what you meant about using LWRP's in lieu of attributes.

My question is - when's the right time to do this and when does it make sense to use normal cookbooks with attributes?

In my case, the cobbler cookbook is exposing LWRP's for some parts of it's configuration ( distros, profiles, etc ). Anything that you can have many of.

However, when you have a singleton service ( ie - the actual 'cobbler' server ), does it make sense to shove it into an LWRP or just stay with the the normal include_recipe and some configuration attributes? Is there somewhere that I missed that using attributes for configuration driven recipes is a bad idea?

--
sh

From: Lamont Granquist lamont@chef.io
Sent: Friday, March 20, 2015 9:20 AM
To: chef@lists.opscode.com
Cc: Hajducko, Steven; Torben Knerr
Subject: Re: [chef] Re: Re: Exposing attributes from cookbooks you depend on

That's ideal philosophically, but is probably going to produce bad chef
code. One you've hit the computed attributes issue and worked around it
by moving setting attributes in recipes and exposed yourself to
compile/converge issues and started down the path of probably needing to
use 'lazy' attributes, then I'd rethink the idea of re-namespacing the
attributes.

On 3/20/15 2:09 AM, Torben Knerr wrote:

My preference on this is to re-namespace the attributes the user is
expected to set. I think of it as the "public interface" of a wrapper
cookbook that is tested and also documented in the README.

Cheers, Torben

On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist lamont@chef.io wrote:

On 3/19/15 1:53 PM, Hajducko, Steven wrote:

Provserv is a wrapper ( and the name is made up ) - it does its own things
as well, so it's probably best to call it an application cookbook that's
depending on another application cookbook. It's also business specific to
us. The cobbler cookbook is meant to, in the end, be shared with the
community.

The cobbler attributes that need to be set however, need to be set per
environment. We'll have several of the 'provserv' applications running,
each in its own environment.

My question was about whether people generally re-namespace these attributes
when you have a cookbook you're depending on and you need to expose those
configurable attributes to the user.

In our case, we'd be setting all these in a Chef environment. But, do I
expose them as:

default["provserv"]["dhcp"]["gateway"] = 1.1.1.1

and in the recipe:

node["cobbler"]["dhcp"]["gateway"] = node["provserv"]["dhcp"]["gateway"]

yeah, don't set that attribute in the recipe.

you probably set it in the recipe because you hit the interpolated
attributes problem in the attributes file.

its better to just use default["cobbler"]["dhcp"]["gateway"] in the
attributes file of the proserv cookbook.

8

We're heading in the direction where library cookbooks should only
expose LWRPs for the most part. All the attributes should be exposed
instead as parameters on LWRPs. Once those resources are mature then
eventually they can get migrated into core chef.

Similar pattern can be used internally so that you'd have LWRPs to wrap
your definition of what a generic 'application' is in your
infrastructure so that the listen_port becomes a parameter instead of an
attribute. Then what attributes get used for is things where you'd like
to twiddle them via roles or role cookbooks. So having one cookbook
which manages /etc/resolv.conf makes sense, but then you might need to
tweak the search path in different roles if you've got some complicated
internal DNS domains on the servers you are managing. You can still do
that via LWRPs but then you need to call that LWRP in every single role
that you have which is going to be more complicated than just having a
base role that manages /etc/resolv.conf and then exposes attributes to
override. I'd probably use attributes in that case, and it makes it
naturally searchable and that distinction is something that I'd probably
like to search on and see in the node data.

So instead of using attributes for everything, start with LWRPs, and
then use attributes when their properties are actually desired.

Sean O'Meara has been giving talks about this, he'll be talking about it
at ChefConf, I think there's blog posts and slides up on the web
somewhere but I'm not sure where...

On 3/20/15 9:24 AM, Hajducko, Steven wrote:

So I read over the httpd and mysql and saw what you meant about using LWRP's in lieu of attributes.

My question is - when's the right time to do this and when does it make sense to use normal cookbooks with attributes?

In my case, the cobbler cookbook is exposing LWRP's for some parts of it's configuration ( distros, profiles, etc ). Anything that you can have many of.

However, when you have a singleton service ( ie - the actual 'cobbler' server ), does it make sense to shove it into an LWRP or just stay with the the normal include_recipe and some configuration attributes? Is there somewhere that I missed that using attributes for configuration driven recipes is a bad idea?

--
sh

From: Lamont Granquist lamont@chef.io
Sent: Friday, March 20, 2015 9:20 AM
To: chef@lists.opscode.com
Cc: Hajducko, Steven; Torben Knerr
Subject: Re: [chef] Re: Re: Exposing attributes from cookbooks you depend on

That's ideal philosophically, but is probably going to produce bad chef
code. One you've hit the computed attributes issue and worked around it
by moving setting attributes in recipes and exposed yourself to
compile/converge issues and started down the path of probably needing to
use 'lazy' attributes, then I'd rethink the idea of re-namespacing the
attributes.

On 3/20/15 2:09 AM, Torben Knerr wrote:

My preference on this is to re-namespace the attributes the user is
expected to set. I think of it as the "public interface" of a wrapper
cookbook that is tested and also documented in the README.

Cheers, Torben

On Thu, Mar 19, 2015 at 11:07 PM, Lamont Granquist lamont@chef.io wrote:

On 3/19/15 1:53 PM, Hajducko, Steven wrote:

Provserv is a wrapper ( and the name is made up ) - it does its own things
as well, so it's probably best to call it an application cookbook that's
depending on another application cookbook. It's also business specific to
us. The cobbler cookbook is meant to, in the end, be shared with the
community.

The cobbler attributes that need to be set however, need to be set per
environment. We'll have several of the 'provserv' applications running,
each in its own environment.

My question was about whether people generally re-namespace these attributes
when you have a cookbook you're depending on and you need to expose those
configurable attributes to the user.

In our case, we'd be setting all these in a Chef environment. But, do I
expose them as:

default["provserv"]["dhcp"]["gateway"] = 1.1.1.1

and in the recipe:

node["cobbler"]["dhcp"]["gateway"] = node["provserv"]["dhcp"]["gateway"]

yeah, don't set that attribute in the recipe.

you probably set it in the recipe because you hit the interpolated
attributes problem in the attributes file.

its better to just use default["cobbler"]["dhcp"]["gateway"] in the
attributes file of the proserv cookbook.

9

What is a good rule of thumb for naming roles, cookbooks, recipes. etc.
I noticed we have two recipes both named amanda_installer.rb one for mac
and the other is for RHEL. That doesn’t sound like that’s right.
Shouldn’t we name things by the os or something so you can tell what it
is or is the point to make everything super generic?

Have a great weekend.

Cheers.

Michael D. Mosier
Systems Guy
University Of Texas
Astro Physics

10

In that case, I'd have one cookbook and can do both operating systems.

Kent

On Fri, Mar 20, 2015 at 12:50 PM, michael david mosier <
mdm4435@astro.as.utexas.edu> wrote:

What is a good rule of thumb for naming roles, cookbooks, recipes. etc. I
noticed we have two recipes both named amanda_installer.rb one for mac and
the other is for RHEL. That doesn't sound like that's right. Shouldn't we
name things by the os or something so you can tell what it is or is the
point to make everything super generic?

Have a great weekend.

Cheers.

Michael D. Mosier
Systems Guy
University Of Texas
Astro Physics

11

Chef doesn't force you to do this kind of thing one way or another. You
should aim to write recipes that can be applied to as many systems as
possible, and the way Chef is designed can help a lot with that, but it's
not always possible. Certainly the differences between OSX and RHEL can
warrant having separate recipes, even just for the sake of clarity.
You could just have a single recipe that does something like this (and this
isn't real code obviously):

case 'os'
when 'osx'
do a and b
when 'rhel'
do c and d
end

do more things that work regardless of the OS

Or you can do something like this in the default recipe:

do foo # this works regardless of the OS
do bar # and so does this

include_recipe "mycookbook::#{node['os']}"

and have a recipe for each OS type you wish your cookbook to support.

https://github.com/L2G/timezone-ii/blob/master/recipes/default.rb is an
example of the latter.

On Fri, Mar 20, 2015 at 1:50 PM, michael david mosier <
mdm4435@astro.as.utexas.edu> wrote:

What is a good rule of thumb for naming roles, cookbooks, recipes. etc. I
noticed we have two recipes both named amanda_installer.rb one for mac and
the other is for RHEL. That doesn't sound like that's right. Shouldn't we
name things by the os or something so you can tell what it is or is the
point to make everything super generic?

Have a great weekend.

Cheers.

Michael D. Mosier
Systems Guy
University Of Texas
Astro Physics

12

i prefer to name cookbooks as actual program/deamon/software they are
running. like mysql, haproxy, nginx, etc. All top level node assignments
are via roles, and role names indicate the key component (like mysql,
nginx, etc) + customizations or ops requirement on top of it (like nrpe
agent, logstash etc), generally these ops requirements are modeled as base
role, and top level roles become base + recipe . For services (i.e. your
own code), roles and recipes reflect the same pattern. Some time a
service/role is consolidation of base + recipe[Y] + recipe[Z]. Usage of
environments really depends on how many chef server you use, whether its
chef 11 server or 12 server etc. depending upon these you can either use
environment as prod/test/dev etc (if you share one chef server across
environemnt) or use them service specific cluster (e.g. prod-x , prod-Y,
prod-geren-X, prod-blue-Y in prod chef server, while test-x, test-y,
test-green-x etc in test chef server).

Since all these are convention based (as in chef dont enforce these
things), you get to choose how you want to model it. If the volume of code
thats different from RHEL to OSX is high enough, and their dependencies are
also very different, it makes lot of sense to keep them in different
cookbooks. If not you can choose to make them sub recipes inside a single
cookbook.

regards
ranjib

On Fri, Mar 20, 2015 at 10:50 AM, michael david mosier <
mdm4435@astro.as.utexas.edu> wrote:

What is a good rule of thumb for naming roles, cookbooks, recipes. etc. I
noticed we have two recipes both named amanda_installer.rb one for mac and
the other is for RHEL. That doesn't sound like that's right. Shouldn't we
name things by the os or something so you can tell what it is or is the
point to make everything super generic?

Have a great weekend.

Cheers.

Michael D. Mosier
Systems Guy
University Of Texas
Astro Physics

13

On Fri, Mar 20, 2015 at 12:53 PM, Lamont Granquist lamont@chef.io wrote:

Sean O'Meara has been giving talks about this, he'll be talking about it at
ChefConf, I think there's blog posts and slides up on the web somewhere but
I'm not sure where...

Sean's slides on this topic are here.

  • Julian
14

@Lamont, thanks for the reminder. So far I'm setting attributes in
recipes (=> computed attributes) but have not come to lazy attributes
yet. Must have been lucky :wink:

That slide deck from Sean O'Meara is both beautiful and super relevant!

Chef should set out a bounty for each supermarket cookbook that is
converted to a LWRP library cookbook by the community. I wish all
cookbooks were like the httpd one already... :slight_smile:

On Fri, Mar 20, 2015 at 9:07 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Fri, Mar 20, 2015 at 12:53 PM, Lamont Granquist lamont@chef.io wrote:

Sean O'Meara has been giving talks about this, he'll be talking about it at
ChefConf, I think there's blog posts and slides up on the web somewhere but
I'm not sure where...

Sean's slides on this topic are here.
Configuration Management Camp 2015 | PPT

  • Julian
15

...and I guess using poise [0] is one of the easiest ways of writing
reusable resources these days?

[0] GitHub - poise/poise: A set of libraries for writing reusable Chef cookbooks

On Sat, Mar 21, 2015 at 2:58 PM, Torben Knerr mail@tknerr.de wrote:

@Lamont, thanks for the reminder. So far I'm setting attributes in
recipes (=> computed attributes) but have not come to lazy attributes
yet. Must have been lucky :wink:

That slide deck from Sean O'Meara is both beautiful and super relevant!

Chef should set out a bounty for each supermarket cookbook that is
converted to a LWRP library cookbook by the community. I wish all
cookbooks were like the httpd one already... :slight_smile:

On Fri, Mar 20, 2015 at 9:07 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Fri, Mar 20, 2015 at 12:53 PM, Lamont Granquist lamont@chef.io wrote:

Sean O'Meara has been giving talks about this, he'll be talking about it at
ChefConf, I think there's blog posts and slides up on the web somewhere but
I'm not sure where...

Sean's slides on this topic are here.
Configuration Management Camp 2015 | PPT

  • Julian
16

...oh, and GitHub - chef-boneyard/resource: DEPRECATED: Easier, More Powerful Chef Resources from jkeiser
looks pretty neat as well!

On Sat, Mar 21, 2015 at 3:37 PM, Torben Knerr mail@tknerr.de wrote:

...and I guess using poise [0] is one of the easiest ways of writing
reusable resources these days?

[0] GitHub - poise/poise: A set of libraries for writing reusable Chef cookbooks

On Sat, Mar 21, 2015 at 2:58 PM, Torben Knerr mail@tknerr.de wrote:

@Lamont, thanks for the reminder. So far I'm setting attributes in
recipes (=> computed attributes) but have not come to lazy attributes
yet. Must have been lucky :wink:

That slide deck from Sean O'Meara is both beautiful and super relevant!

Chef should set out a bounty for each supermarket cookbook that is
converted to a LWRP library cookbook by the community. I wish all
cookbooks were like the httpd one already... :slight_smile:

On Fri, Mar 20, 2015 at 9:07 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Fri, Mar 20, 2015 at 12:53 PM, Lamont Granquist lamont@chef.io wrote:

Sean O'Meara has been giving talks about this, he'll be talking about it at
ChefConf, I think there's blog posts and slides up on the web somewhere but
I'm not sure where...

Sean's slides on this topic are here.
Configuration Management Camp 2015 | PPT

  • Julian
17

Thank you everyone for helping me with naming conventions.

I have another question. Again I am fairly new to this so I may have
just not learned how this works yet.

If someone has 1000 nodes. Going to each machine and running chef-client
doesn’t feel like it’s the best way to do things. I know on the
enterprise side they have a push type plugin. I also know with knife I
can force a push to all the nodes. The problem I see with this is you
may need to write an error handler into a recipe so you will know that
something that was just updated on the node errored out. If your on each
machine you can see on the screen if it errored out when you run
chef-client but remotely I am not sure how to handle catching errors. I
was thinking since there are two built in error handlers maybe I could
write a script that would email me whenever an error occurs but that may
mean that each node has to have send-mail running.

  1. How do you all deal with updating multiple nodes without SSHing to
    each and running chef-client

  2. How do you all deal with error handling.

Thank yo so much

Michael D. Mosier
Systems Guy
University Of Texas
Astro Physics

18

For my personnal use case (and there's others) I'm using rundeck to
launch chef on nodes (one solution on many).

If a run ends in error it's marked as failed and I can relaunch on
failed nodes easily.

I do use rundeck for specific 'need now' run, for the rest I rely on a
crontab job launching chef with a report/error handler which report back
to a dashboard the updated resources, and some other specific needs
(attributes accessed in our namespace, GAV of artifact deployed from
nexus on this machine, cookbook version used, etc.)

I do keep hope we can open source it on github one day.

There's a lot of way to do this, which one is the good for you depends a
lot of your interest of a run result and how you want to act on failure.

My 2 cents on this subject, hope it will help.

Le 2015-03-23 12:43, michael david mosier a écrit :

Thank you everyone for helping me with naming conventions.

I have another question. Again I am fairly new to this so I may have just not learned how this works yet.

If someone has 1000 nodes. Going to each machine and running chef-client doesn't feel like it's the best way to do things. I know on the enterprise side they have a push type plugin. I also know with knife I can force a push to all the nodes. The problem I see with this is you may need to write an error handler into a recipe so you will know that something that was just updated on the node errored out. If your on each machine you can see on the screen if it errored out when you run chef-client but remotely I am not sure how to handle catching errors. I was thinking since there are two built in error handlers maybe I could write a script that would email me whenever an error occurs but that may mean that each node has to have send-mail running.

  1. How do you all deal with updating multiple nodes without SSHing to each and running chef-client

  2. How do you all deal with error handling.

Thank yo so much

Michael D. Mosier
Systems Guy
University Of Texas
Astro Physics

19

Hi Michael!

In our environments, we run Chef as a daemon, and it executes every 30
minutes (or so, depending on splay).

We use the chef-handler-datadog plugin 1 (I work at Datadog, so that
seemed likely), which will report the status to Chef Runs in a nice,
aggregated manner 2.

Best,
-M

On Mon, Mar 23, 2015 at 7:43 AM, michael david mosier <
mdm4435@astro.as.utexas.edu> wrote:

Thank you everyone for helping me with naming conventions.

I have another question. Again I am fairly new to this so I may have just
not learned how this works yet.

If someone has 1000 nodes. Going to each machine and running chef-client
doesn't feel like it's the best way to do things. I know on the enterprise
side they have a push type plugin. I also know with knife I can force a
push to all the nodes. The problem I see with this is you may need to write
an error handler into a recipe so you will know that something that was
just updated on the node errored out. If your on each machine you can see
on the screen if it errored out when you run chef-client but remotely I am
not sure how to handle catching errors. I was thinking since there are two
built in error handlers maybe I could write a script that would email me
whenever an error occurs but that may mean that each node has to have
send-mail running.

  1. How do you all deal with updating multiple nodes without SSHing to each
    and running chef-client

  2. How do you all deal with error handling.

Thank yo so much

Michael D. Mosier
Systems Guy
University Of Texas
Astro Physics

20

we use hipchat for immediate notification when chef run fails. and the dd
plugins, to create fine grained alerts.

we have written blender to automate the push/coordination needs, for on
demand we use the ssh driver , and for periodic fleetwide run we use serf
backend (scales way better than ssh),

I'll recommend to use the hipchat or dd or any other error handler
irrespective of the push workflow bit,

[0]https://help.hipchat.com/knowledgebase/articles/65276-chef-integration
[1]GitHub - PagerDuty/blender: A modular orchestration engine
[2]GitHub - PagerDuty/blender-chef: Chef search based host discovery for blender.

On Mon, Mar 23, 2015 at 4:43 AM, michael david mosier <
mdm4435@astro.as.utexas.edu> wrote:

Thank you everyone for helping me with naming conventions.

I have another question. Again I am fairly new to this so I may have just
not learned how this works yet.

If someone has 1000 nodes. Going to each machine and running chef-client
doesn't feel like it's the best way to do things. I know on the enterprise
side they have a push type plugin. I also know with knife I can force a
push to all the nodes. The problem I see with this is you may need to write
an error handler into a recipe so you will know that something that was
just updated on the node errored out. If your on each machine you can see
on the screen if it errored out when you run chef-client but remotely I am
not sure how to handle catching errors. I was thinking since there are two
built in error handlers maybe I could write a script that would email me
whenever an error occurs but that may mean that each node has to have
send-mail running.

  1. How do you all deal with updating multiple nodes without SSHing to each
    and running chef-client

  2. How do you all deal with error handling.

Thank yo so much

Michael D. Mosier
Systems Guy
University Of Texas
Astro Physics