That's not what I mean at all.
When you construct your nodes you want to be consistent. If you want a
server of a specific function you should use the same run list for that
node in all cases, for every environment. You achieve this by either having
a role with this run_list or by assigning the run list directly to a node.
You use your environments to override any settings that are applied as
defaults to a role, or to give new settings that are specific to that
environment.
If you have a server type (role) which is only unique when that particular
role is in a particular environment then you need to either apply
attributes directly to the node or have your recipe be smart enough to work
out what environment it is in, if you have control of the recipe.
In the case where you have control of the recipe, either via a wrapper
cookbook or a cookbook in which you can control the recipes, then you would
do it something like this:
if node.chef_environment == 'production' node.force_override['thing'] =
'foo' Chef::Log.warn('production')else node.force_override['thing'] =
'bar' Chef::Log.warn('not production')endinclude_recipe 'something'
This could be a recipe in your base cookbook that you only apply to the
role that thing change has meaning for, early in the run list.
Finally, if you are adding the openssh recipe as a part of the role run
list directly, not being called by *include_recipe 'openssh::default' *in
a recipe that you control, then your only option is to use node attributes
for those nodes, at the force_override priority if you are using override
in your environment. You will need to take care of adding the attributes to
the node when the node is created in chef. If you're using knife to make
the instances then you can pass the -j flag and a json file containing
attributes, otherwise it depends on how the instances are created.
On Thu, Jun 18, 2015 at 5:03 PM, Douglas Garstang doug.garstang@gmail.com
wrote:
I realise that my top level run list would contain something like env-dev,
base, some_foo. I also realise that for individual cookbooks I'd have to
set attributes in my Vagrantfile, which I really don't like because it then
means I'm not actually testing the same thing as what the env-dev cookbook
contains. However, it gets really bad when you want to test the base
cookbook. I'd have to replicate every attribute from every other cookbook
that's included into the Vagrantfile. It also means that if I add a new
cookbook to the base role, I have to manually add it's attributes each time
as well. This option does not scale.
Doug.
On Thu, Jun 18, 2015 at 4:48 PM, Douglas Garstang <doug.garstang@gmail.com
wrote:
So... if I had one cookbook per environment, how on earth do cookbook
dependencies work? I can't put them ALL into metadata.rb and Berksfile...
Doug.
On Thu, Jun 18, 2015 at 4:31 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:
As I was saying the only annoying part of this is that I have to include
this recipe before any others that contain *include_recipe 'sshd' *so
that my recipe override works, which I feel there must be a way around.
On Thu, Jun 18, 2015 at 4:30 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:
You don't necessarily have to make a wrapper cookbook to override one
attribute. Do it where it's needed.
I do this in one of my recipes to enable ssh password authentication on
one type of node but have it disabled by default for all others:
node.override['sshd']['sshd_config']['PasswordAuthentication'] = 'yes'
include_recipe 'sshd'
This is in my recipe that creates a user with a specific password. This
recipe is only run against nodes that need this user. Below this I have
user 'myuser' do
home '/foo/bar'
shell '/foo/bar'
end
And everything else the recipe does.
Making a wrapper cookbook only makes sense if multiple different types
of systems use the same attribute overrides every time, or if you want to
add further recipes to the base cookbook.
In your case you just want one type of server to do one very specific
thing, so just do it in the recipe that configures that type of node,
whether that's in a role cookbook or anywhere else.
On Thu, Jun 18, 2015 at 4:23 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:
Yoshi.
Your saying to override the attributes in a recipe... I don't have a
cookbook for openssh. I'm using the community cookbook. To do what your
suggesting, I'd have to create a wrapper cookbook just for the purposes of
setting an attribute that's only used on one class of machine. I don't
think that's a good idea.
Doug.
On Thu, Jun 18, 2015 at 4:20 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:
Yes, but do those nodes run a particular recipe that others don't?
Because you can put the override in your recipe, not your cookbook
attributes.
Use node.force_override['my']['attribute'] in the recipe code.
Otherwise you can set a node attribute directly as force_override
priority.
I feel like you're getting into some sticky territory here that
better design can help with...
On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:
Yoshi.
I can't use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).
Douglas.
On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:
If you do away with role attributes entirely and put them in role
cookbooks then you don't have to use override on environments.
Alternatively you can set this on the nodes directly at
force_override or in the recipe itself at force_override if you really have
to, although I really would recommend designing your cookbooks in such a
way that you don't have to much around with attribute priorities all over
the place.
On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:
I should add that the reason I can't set this attribute at level
13 or 14 is that it should only be set on instances of a certain role, not
all instances. I can't set it via an override attribute at position 12
because I don't want all instances in a given environment to receive it.
On Thu, Jun 18, 2015 at 3:26 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:
Thanks Galen.
I've already hit a snag with this approach. I'm setting common
attributes in a recipe (#2), and overriding environmental attributes in an
environment (#12). However, I have a cookbook that needs to modify a single
attribute to the openssh cookbook. I don't know where I could put this.
There's only 2 places it can go that have higher precedence than #12, and
neither of those are a role. :~(
Doug.
On Thu, Jun 18, 2015 at 1:56 PM, Galen Emery galen@getchef.com
wrote:
Doug,
the levels you suggested are the ones we typically recommend.
The way I teach people is the following:
Cookbook attributes file: use default.
Roles: Use Default
Environments: Use Override.
There's a bunch of other precedence levels and while helpful for
debug, can drive you nuts if you're using in production.
On Thu, Jun 18, 2015 at 1:53 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:
Everything gets merged together. Your attribute set at the end
is the result of all levels and locations being merged together and the
highest precedence winning.
On Thu, Jun 18, 2015 at 1:49 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:
Sounds .... complicated.
I don't think I have a complex enough environment to justify
that yet. Looking at the attributes precedence docs, it looks like I could
set common attributes as default attributes in a role (#4) and then
override with a override attribute in an environment (#12). In this
situation though, would the two hashes me merged together?
Doug.
On Thu, Jun 18, 2015 at 1:35 PM, Ranjib Dey <
dey.ranjib@gmail.com> wrote:
oh btw.. i dont use chef's attribute precedence heavily ..
most of the attribute customization are spread across standard default
precedence level, (recipe, wrappers, environments, roles ), the deep_merge
yaml trick. this allows me to bypass most of the so called role-env,
role-recipe etc etc patterns, and eases deduction. I still use the higher
precedence levels sporadically (like canary releases, CVE patches etc),
more like for surgical cases
On Thu, Jun 18, 2015 at 1:30 PM, Ranjib Dey <
dey.ranjib@gmail.com> wrote:
i use environment heavily as well, and face the same
problem. The trick i use is have a environments/common folder which
container coomon things in yaml file (or ruby if you like) that is just
data. Top level environments (say environments/foo.rb) can directly read
that yaml, and deep_merge! (one of dans many awesome works 
) that
directly in default_attributes method. this allows me to keep the common
data and reuse it.,
hope that helps.
On Thu, Jun 18, 2015 at 10:48 AM, Douglas Garstang <
doug.garstang@gmail.com> wrote:
All,
I'm making pretty heavy use of environments. There's quite
a fair bit of duplication and I'd like to implement a 'base' environment,
with common attributes that apply to all environments. How would I do this?
What happens if the same attribute is defined in multiple
environments? Are they merged together or does the 'inherited' one override
the 'base' one?
Thanks,
Doug
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Galen Emery
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com