Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain recipes from this cookbook.
Phil Oliva
No, this is not a feature available in Chef. You can rig it up in any number of ways (cron job that adds a specific role, build scripts to enforce it, etc) but Chef itself will not.
--Noah
On Sep 24, 2014, at 10:03 AM, Phil Oliva poliva@blackberry.com wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain recipes from this cookbook.
Phil Oliva
I'm not sure if this will fit your use case exactly, but during the
bootstrap itself you can specific a specific run list with a json file
using knife bootstrap with the -j flag as documented here:
If you are looking for 'extra' recipes not on the runlist, Noah is correct.
On Wed, Sep 24, 2014 at 10:08 AM, Noah Kantrowitz noah@coderanger.net
wrote:
No, this is not a feature available in Chef. You can rig it up in any
number of ways (cron job that adds a specific role, build scripts to
enforce it, etc) but Chef itself will not.--Noah
On Sep 24, 2014, at 10:03 AM, Phil Oliva poliva@blackberry.com wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to
certain chef-server run extra recipe(s) on top of their specified run list?
Basically want to create a base cookbook for my organization and ensure all
managed bootstrap nodes have run certain recipes from this cookbook.Phil Oliva
--
Scott Hain — Software Development Engineer
360.360.7433 – shain@getchef.com – *my: *Linkedin http://www.linkedin.com/
Twitter http://www.twitter.com/elejia
CHEF
GETCHEF.COM http://www.getchef.com/
TM
getchef.com http://www.getchef.com/ Blog
http://www.opscode.com/blog/ Facebook
https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef
Thanks Noah, I will try one of your suggested options.
-----Original Message-----
From: Noah Kantrowitz [mailto:noah@coderanger.net]
Sent: Wednesday, September 24, 2014 1:09 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Enforce certain recipe in run_list
No, this is not a feature available in Chef. You can rig it up in any number of ways (cron job that adds a specific role, build scripts to enforce it, etc) but Chef itself will not.
--Noah
On Sep 24, 2014, at 10:03 AM, Phil Oliva poliva@blackberry.com wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain recipes from this cookbook.
Phil Oliva
Yes, I am familiar with the –j option. We use ‘chef-client –j http://fakefile.json’ quite often to specify vm instance attributes. Just a co-worker suggested to me that you could get specify something on chef-server to enforce ‘extra’ recipes to be run for all nodes but couldn’t find any documentation related to this claim. Just thought I’d ask.
From: Scott Hain [mailto:shain@getchef.com]
Sent: Wednesday, September 24, 2014 1:12 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Enforce certain recipe in run_list
I'm not sure if this will fit your use case exactly, but during the bootstrap itself you can specific a specific run list with a json file using knife bootstrap with the -j flag as documented here: http://docs.getchef.com/install_bootstrap.html
If you are looking for 'extra' recipes not on the runlist, Noah is correct.
On Wed, Sep 24, 2014 at 10:08 AM, Noah Kantrowitz <noah@coderanger.netmailto:noah@coderanger.net> wrote:
No, this is not a feature available in Chef. You can rig it up in any number of ways (cron job that adds a specific role, build scripts to enforce it, etc) but Chef itself will not.
--Noah
On Sep 24, 2014, at 10:03 AM, Phil Oliva <poliva@blackberry.commailto:poliva@blackberry.com> wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain recipes from this cookbook.
Phil Oliva
--
Scott Hain — Software Development Engineer
360.360.7433 – shain@getchef.commailto:shain@getchef.com – my: Linkedinhttp://www.linkedin.com/ Twitterhttp://www.twitter.com/elejia
CHEF
GETCHEF.COMhttp://www.getchef.com/
TM
getchef.comhttp://www.getchef.com/ Bloghttp://www.opscode.com/blog/ Facebookhttps://www.facebook.com/getchefdotcom Twitterhttps://twitter.com/chef Youtubehttps://www.youtube.com/getchef
You can use environment run list to enforce certain roles or recipes across
all nodes from that environment. You have to specify these across all
environments.
Base roles are more popular for this use case 
On Sep 24, 2014 10:03 AM, "Phil Oliva" poliva@blackberry.com wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to
certain chef-server run extra recipe(s) on top of their specified run list?
Basically want to create a base cookbook for my organization and ensure all
managed bootstrap nodes have run certain recipes from this cookbook.Phil Oliva
On Sep 24, 2014, at 10:25 AM, Ranjib Dey ranjib@pagerduty.com wrote:
You can use environment run list to enforce certain roles or recipes across all nodes from that environment. You have to specify these across all environments.
Base roles are more popular for this use case
No, environments do not have run lists. Also the default "_default" environment is immutable anyway.
--Noah
This could be an interesting feature 
Le 24 sept. 2014 19:29, "Noah Kantrowitz" noah@coderanger.net a écrit :
On Sep 24, 2014, at 10:25 AM, Ranjib Dey ranjib@pagerduty.com wrote:
You can use environment run list to enforce certain roles or recipes
across all nodes from that environment. You have to specify these across
all environments.
Base roles are more popular for this use caseNo, environments do not have run lists. Also the default "_default"
environment is immutable anyway.--Noah
Probably a good one for an RFC and/or discussion at the Chef Summit.
On Wed Sep 24 11:42:05 2014, Olivier Bazoud wrote:
This could be an interesting feature
Le 24 sept. 2014 19:29, "Noah Kantrowitz" <noah@coderanger.net
mailto:noah@coderanger.net> a écrit :On Sep 24, 2014, at 10:25 AM, Ranjib Dey <ranjib@pagerduty.com <mailto:ranjib@pagerduty.com>> wrote: > You can use environment run list to enforce certain roles or recipes across all nodes from that environment. You have to specify these across all environments. > Base roles are more popular for this use case :-) > No, environments do not have run lists. Also the default "_default" environment is immutable anyway. --Noah
Roles can declare environment-specific run lists though: https://docs.getchef.com/essentials_roles.html#set-per-environment-run-lists
Maybe this is what Ranjib meant?
am
On 24 Sep 2014, at 22:27, Lamont Granquist lamont@opscode.com wrote:
Probably a good one for an RFC and/or discussion at the Chef Summit.
On Wed Sep 24 11:42:05 2014, Olivier Bazoud wrote:
This could be an interesting feature
Le 24 sept. 2014 19:29, "Noah Kantrowitz" <noah@coderanger.net
mailto:noah@coderanger.net> a écrit :On Sep 24, 2014, at 10:25 AM, Ranjib Dey <ranjib@pagerduty.com
mailto:ranjib@pagerduty.com> wrote:You can use environment run list to enforce certain roles or
recipes across all nodes from that environment. You have to
specify these across all environments.
Base roles are more popular for this use caseNo, environments do not have run lists. Also the default
"_default" environment is immutable anyway.--Noah
yeah., but as noah mentioned, and i just confirmed with pry., i dont see a
run_list on the Chef::Environment objects. neither i can find any reference
on lib/chef/environment.rb. But this is the same link i had read (long time
before), may be this is wrong documentation, or a deprecated feature..
On Wed, Sep 24, 2014 at 1:20 PM, Aimelyne Mochiron aimelynem@gmail.com
wrote:
Roles can declare environment-specific run lists though:
https://docs.getchef.com/essentials_roles.html#set-per-environment-run-listsMaybe this is what Ranjib meant?
am
On 24 Sep 2014, at 22:27, Lamont Granquist lamont@opscode.com wrote:
Probably a good one for an RFC and/or discussion at the Chef Summit.
On Wed Sep 24 11:42:05 2014, Olivier Bazoud wrote:
This could be an interesting feature
Le 24 sept. 2014 19:29, "Noah Kantrowitz" <noah@coderanger.net
mailto:noah@coderanger.net> a écrit :On Sep 24, 2014, at 10:25 AM, Ranjib Dey <ranjib@pagerduty.com
mailto:ranjib@pagerduty.com> wrote:You can use environment run list to enforce certain roles or
recipes across all nodes from that environment. You have to
specify these across all environments.
Base roles are more popular for this use caseNo, environments do not have run lists. Also the default
"_default" environment is immutable anyway.--Noah
I think you can specify a run list using environments, but only roles will
be catered
@dan am I right here?
On Wed, Sep 24, 2014 at 1:35 PM, Ranjib Dey ranjib@pagerduty.com wrote:
yeah., but as noah mentioned, and i just confirmed with pry., i dont see a
run_list on the Chef::Environment objects. neither i can find any reference
on lib/chef/environment.rb. But this is the same link i had read (long time
before), may be this is wrong documentation, or a deprecated feature..On Wed, Sep 24, 2014 at 1:20 PM, Aimelyne Mochiron aimelynem@gmail.com
wrote:Roles can declare environment-specific run lists though:
https://docs.getchef.com/essentials_roles.html#set-per-environment-run-listsMaybe this is what Ranjib meant?
am
On 24 Sep 2014, at 22:27, Lamont Granquist lamont@opscode.com wrote:
Probably a good one for an RFC and/or discussion at the Chef Summit.
On Wed Sep 24 11:42:05 2014, Olivier Bazoud wrote:
This could be an interesting feature
Le 24 sept. 2014 19:29, "Noah Kantrowitz" <noah@coderanger.net
mailto:noah@coderanger.net> a écrit :On Sep 24, 2014, at 10:25 AM, Ranjib Dey <ranjib@pagerduty.com
mailto:ranjib@pagerduty.com> wrote:You can use environment run list to enforce certain roles or
recipes across all nodes from that environment. You have to
specify these across all environments.
Base roles are more popular for this use caseNo, environments do not have run lists. Also the default
"_default" environment is immutable anyway.--Noah
On Wednesday, September 24, 2014 at 1:41 PM, Ranjib Dey wrote:
I think you can specify a run list using environments, but only roles will be catered
https://github.com/opscode/chef/blob/master/lib/chef/run_list/run_list_expansion.rb#L151@dan am I right here?
That line just selects the environment-specific run list for the role.
--
Daniel DeLeo
Nothing deprecated nor wrong. It is role run list per environment. You still have to add the role to the node running, so it's not answering the problem.
The only way I think of is a cron searching nodes without the recipe and adding it.
Maybe with something like knife-audit (unsure of the name) or a search pattern...
Envoyé à partir de mon smartphone Sony Xperia™
---- Ranjib Dey a écrit ----
yeah., but as noah mentioned, and i just confirmed with pry., i dont see a run_list on the Chef::Environment objects. neither i can find any reference on lib/chef/environment.rb. But this is the same link i had read (long time before), may be this is wrong documentation, or a deprecated feature..
On Wed, Sep 24, 2014 at 1:20 PM, Aimelyne Mochiron aimelynem@gmail.com wrote:
Roles can declare environment-specific run lists though: https://docs.getchef.com/essentials_roles.html#set-per-environment-run-lists
Maybe this is what Ranjib meant?
am
On 24 Sep 2014, at 22:27, Lamont Granquist lamont@opscode.com wrote:
Probably a good one for an RFC and/or discussion at the Chef Summit.
On Wed Sep 24 11:42:05 2014, Olivier Bazoud wrote:
This could be an interesting feature
Le 24 sept. 2014 19:29, "Noah Kantrowitz" <noah@coderanger.net
mailto:noah@coderanger.net> a écrit :On Sep 24, 2014, at 10:25 AM, Ranjib Dey <ranjib@pagerduty.com
mailto:ranjib@pagerduty.com> wrote:You can use environment run list to enforce certain roles or
recipes across all nodes from that environment. You have to
specify these across all environments.
Base roles are more popular for this use caseNo, environments do not have run lists. Also the default
"_default" environment is immutable anyway.--Noah
On Wednesday, September 24, 2014 at 10:03 AM, Phil Oliva wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain recipes from this cookbook.
Phil Oliva
To start this one over from the beginning, what do you mean by "ensure all managed bootstrap nodes have run certain recipes from this cookbook?” Are you worried that users in your organization will unintentionally create nodes without these recipes? Or that users will intentionally create nodes without these recipes? Do you need to manage the set of “required” base recipes over time? What kinds of users create new nodes, and how do they specify their customizations?
--
Daniel DeLeo
Daniel,
We're trying to enforce some governance on all the nodes that bootstrapped to our chef server. Coming from a large organization and trying to onboard many groups to our ha chef server infrastructure on our Opennebula based private cloud.
We provided a single bash context script (coined "one init.sh script to rule them all") as a point of entry that groups can put in their vm template context along and with some standardized chef related template variables (chef_server_url, validator_key, bootstrap_json, chef_environment, etc..). Our bash script installs the recommended chef client package version (our team determines which version will get used) then runs chef-apply blocks to setup vm networking (nice because resources work on RH + Ubuntu ) and then setups up the /etc/chef/chef-client.rb properly and runs chef-client based on variables provided. This approach has worked well thus far.
We also wrote a hook for our hypervisors to cleanup node/client data when vms get deleted/recreated. Our chef server has a special admin account for that hypervisors can use to run pychef and manage it.
That was all the logic we wanted to add to init.sh script. Anything that needs to be done to node after chef-client is assumed to be in a cookbook. Don't want to modify the init.sh very often (ideally never).
So I wanted to create a base cookbook that has a recipe that forces nodes checking every 15 minutes into server with chef-client runs using a cron or chef-client daemon. This recipe would need to survive a DR scenarios if our chef server ended up needing to be recreated and data loss was present. Example if node/client data not on server and vm still has client.pem (delete client.pem if getting "Failed to authenticate to .* with key /etc/chef/client.pem" message).
My question came about because I had an idea that I wanted our staging HA chef server to force people to run this recipe/cookbook even if they didn't specify it in their own run_list. This way people would learn if their cookbooks were truly idempotent (which is our end goal) in testing lab before it ended up in production. If people choose to proceed to production with non-idempotent cookbooks well then operators would need to know they would need to destroy vm and recreate any time they want cookbook rerun.
Phil
----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Wednesday, September 24, 2014 4:47 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Enforce certain recipe in run_list
On Wednesday, September 24, 2014 at 10:03 AM, Phil Oliva wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain recipes from this cookbook.
Phil Oliva
To start this one over from the beginning, what do you mean by "ensure all managed bootstrap nodes have run certain recipes from this cookbook?” Are you worried that users in your organization will unintentionally create nodes without these recipes? Or that users will intentionally create nodes without these recipes? Do you need to manage the set of “required” base recipes over time? What kinds of users create new nodes, and how do they specify their customizations?
--
Daniel DeLeo
I can’t think of a way to enforce that except for a “thou shalt always add the X role to thy VM’s” and a cluebat to enforce it. Perhaps someone else can think of something.
We have a ‘base’ role that gets applied to absolutely every node we have, VM’s or not, that contain things like chef client config, ntp, timezone, base syslog, collectd, etc, and while we’ve never had to enforce it (small team etc) if I had to start enforcing it I’d probably setup a script that polled the node configs and add the base role back into the run_list if it wasn’t there already. And then haul out the aforementioned cluebat and chase down the offender. 
cheers
mike
–
Michael Hart
Arctic Wolf Networks
M: 226-388-4773
On Sep 25, 2014, at 11:53, Phil Oliva <poliva@blackberry.commailto:poliva@blackberry.com> wrote:
Daniel,
We’re trying to enforce some governance on all the nodes that bootstrapped to our chef server. Coming from a large organization and trying to onboard many groups to our ha chef server infrastructure on our Opennebula based private cloud.
We provided a single bash context script (coined “one init.sh script to rule them all”) as a point of entry that groups can put in their vm template context along and with some standardized chef related template variables (chef_server_url, validator_key, bootstrap_json, chef_environment, etc…). Our bash script installs the recommended chef client package version (our team determines which version will get used) then runs chef-apply blocks to setup vm networking (nice because resources work on RH + Ubuntu ) and then setups up the /etc/chef/chef-client.rb properly and runs chef-client based on variables provided. This approach has worked well thus far.
We also wrote a hook for our hypervisors to cleanup node/client data when vms get deleted/recreated. Our chef server has a special admin account for that hypervisors can use to run pychef and manage it.
That was all the logic we wanted to add to init.sh script. Anything that needs to be done to node after chef-client is assumed to be in a cookbook. Don’t want to modify the init.sh very often (ideally never).
So I wanted to create a base cookbook that has a recipe that forces nodes checking every 15 minutes into server with chef-client runs using a cron or chef-client daemon. This recipe would need to survive a DR scenarios if our chef server ended up needing to be recreated and data loss was present. Example if node/client data not on server and vm still has client.pem (delete client.pem if getting “Failed to authenticate to .* with key /etc/chef/client.pem” message).
My question came about because I had an idea that I wanted our staging HA chef server to force people to run this recipe/cookbook even if they didn’t specify it in their own run_list. This way people would learn if their cookbooks were truly idempotent (which is our end goal) in testing lab before it ended up in production. If people choose to proceed to production with non-idempotent cookbooks well then operators would need to know they would need to destroy vm and recreate any time they want cookbook rerun.
Phil
----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Wednesday, September 24, 2014 4:47 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: Enforce certain recipe in run_list
On Wednesday, September 24, 2014 at 10:03 AM, Phil Oliva wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain recipes from this cookbook.
Phil Oliva
To start this one over from the beginning, what do you mean by "ensure all managed bootstrap nodes have run certain recipes from this cookbook?” Are you worried that users in your organization will unintentionally create nodes without these recipes? Or that users will intentionally create nodes without these recipes? Do you need to manage the set of “required” base recipes over time? What kinds of users create new nodes, and how do they specify their customizations?
–
Daniel DeLeo
This isn’t really a “solution” and won’t work if your other cookbooks need to inherit anything, but you could potentially do, on a cron, something like:
chef-client -o my-enforced-cookbook
That’d ensure that the cookbook is run, but it’d be wholly-independent from your standard chef-client runs. Nothing is saved to the server with this method, which may or may not break the functionality you’re looking for.
Having this enforced via other means sounds like a pretty useful feature.
-Ameir
From: michael.hart@arcticwolf.commichael.hart@arcticwolf.com
To: chef@lists.opscode.comchef@lists.opscode.com
Sent: Thursday, September 25, 2014
Subject: [chef] Re: Enforce certain recipe in run_list
I can’t think of a way to enforce that except for a “thou shalt always add the X role to thy VM’s” and a cluebat to enforce it. Perhaps someone else can think of something.
We have a ‘base’ role that gets applied to absolutely every node we have, VM’s or not, that contain things like chef client config, ntp, timezone, base syslog, collectd, etc, and while we’ve never had to enforce it (small team etc) if I had to start enforcing
it I’d probably setup a script that polled the node configs and add the base role back into the run_list if it wasn’t there already. And then haul out the aforementioned cluebat and chase down the offender.
cheers
mike
–
Michael Hart
Arctic Wolf Networks
M: 226-388-4773
On Sep 25, 2014, at 11:53, Phil Oliva poliva@blackberry.com wrote:
Daniel,
We’re trying to enforce some governance on all the nodes that bootstrapped to our chef server. Coming from a large organization and trying to onboard many groups to our ha chef server infrastructure on our Opennebula based private cloud.
We provided a single bash context script (coined “one init.sh script to rule them all”) as a point of entry that groups can put in their vm template context along and with some standardized chef related template variables (chef_server_url, validator_key, bootstrap_json,
chef_environment, etc…). Our bash script installs the recommended chef client package version (our team determines which version will get used) then runs chef-apply blocks to setup vm networking (nice because resources work on RH + Ubuntu ) and then setups
up the /etc/chef/chef-client.rb properly and runs chef-client based on variables provided. This approach has worked well thus far.
We also wrote a hook for our hypervisors to cleanup node/client data when vms get deleted/recreated. Our chef server has a special admin account for that hypervisors can use to run pychef and manage it.
That was all the logic we wanted to add to init.sh script. Anything that needs to be done to node after chef-client is assumed to be in a cookbook. Don’t want to modify the init.sh very often (ideally never).
So I wanted to create a base cookbook that has a recipe that forces nodes checking every 15 minutes into server with chef-client runs using a cron or chef-client daemon. This recipe would need to survive a DR scenarios if our chef server ended up needing to
be recreated and data loss was present. Example if node/client data not on server and vm still has client.pem (delete client.pem if getting “Failed to authenticate to .* with key /etc/chef/client.pem” message).
My question came about because I had an idea that I wanted our staging HA chef server to force people to run this recipe/cookbook even if they didn’t specify it in their own run_list. This way people would learn if their cookbooks were truly idempotent (which
is our end goal) in testing lab before it ended up in production. If people choose to proceed to production with non-idempotent cookbooks well then operators would need to know they would need to destroy vm and recreate any time they want cookbook rerun.
Phil
----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Wednesday, September 24, 2014 4:47 PM
Subject: [chef] Re: Enforce certain recipe in run_list
On Wednesday, September 24, 2014 at 10:03 AM, Phil Oliva wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain
recipes from this cookbook.
Phil Oliva
To start this one over from the beginning, what do you mean by "ensure all managed bootstrap nodes have run certain recipes from this cookbook?” Are you worried that users in your organization will unintentionally create nodes without these recipes? Or that
users will intentionally create nodes without these recipes? Do you need to manage the set of “required” base recipes over time? What kinds of users create new nodes, and how do they specify their customizations?
–
Daniel DeLeo
On 9/25/14, 11:40 AM, Michael Hart wrote:
I can’t think of a way to enforce that except for a “thou shalt always
add the X role to thy VM’s” and a cluebat to enforce it. Perhaps
someone else can think of something.We have a ‘base’ role that gets applied to absolutely every node we
have, VM’s or not, that contain things like chef client config, ntp,
timezone, base syslog, collectd, etc, and while we’ve never had to
enforce it (small team etc) if I had to start enforcing it I’d
probably setup a script that polled the node configs and add the base
role back into the run_list if it wasn’t there already. And then haul
out the aforementioned cluebat and chase down the offender.
In an organization where you've got a couple dozen people of various
skill levels working on config management code and they are coming and
going, the cluebat means that you're just going to constantly be angry
at the junior SA someone hired a month ago who did the wrong thing
without knowing any better. Its a lot better to put the cluebat aside
and just not let anyone have a choice over screwing the policy up.
I'll mention again that writing up an RFC for this and/or mentioning it
at the summit would be good.
I agree the cluebat approach isn’t really good, I wrote it partially due to inside joke from when I worked at the same place the original poster.
cheers
mike
–
Michael Hart
Arctic Wolf Networks
M: 226-388-4773
On Sep 25, 2014, at 17:41, Lamont Granquist <lamont@opscode.commailto:lamont@opscode.com> wrote:
On 9/25/14, 11:40 AM, Michael Hart wrote:
I can’t think of a way to enforce that except for a “thou shalt always add the X role to thy VM’s” and a cluebat to enforce it. Perhaps someone else can think of something.
We have a ‘base’ role that gets applied to absolutely every node we have, VM’s or not, that contain things like chef client config, ntp, timezone, base syslog, collectd, etc, and while we’ve never had to enforce it (small team etc) if I had to start enforcing it I’d probably setup a script that polled the node configs and add the base role back into the run_list if it wasn’t there already. And then haul out the aforementioned cluebat and chase down the offender.
In an organization where you’ve got a couple dozen people of various skill levels working on config management code and they are coming and going, the cluebat means that you’re just going to constantly be angry at the junior SA someone hired a month ago who did the wrong thing without knowing any better. Its a lot better to put the cluebat aside and just not let anyone have a choice over screwing the policy up.
I’ll mention again that writing up an RFC for this and/or mentioning it at the summit would be good.