[chef] Re: Re: Re: Puppet+Hiera vs. Chef, or handling the occasional special snowflake server

[Yoshi Spendiff < >]

Attributes on the node object are only overwritten in the Chef run if there is something in the recipe code which specifically alters that attribute. The node object is both the desired state and current state of the object (although there's future work to split that planned I believe).

So for example if you directly edit a node and set the following attributes

{

  "normal": {

    "myattributes": {
      "foo": true,

      "bar": true

    }

  }

}

Then they become available to recipe code under node['myattributes']['foo'] and node['myattributes']['bar']. If the recipe code specificies something like this:

node.set['myattributes']['bar'] = false then at the end of the Chef run the chef-client will upload any updated node state to the Chef server, which would change the attributes to this:

{

  "normal": {

    "myattributes": {
      "foo": true,

      "bar": false

    }

  }

}

But notice that node['myattributes']['foo'] is still the same as what you set because it wasn't altered in a recipe. So you can set attributes on the node object and use them in recipes without their values being changed by Chef runs.

In terms of the merging of multiple attributes from different sources the end result of attributes available to a Chef run is a merger of all of the attributes of all precedence levels of all sources. I'm not aware of any specific simple string merger like you said but it's something that can easily be done in recipe code (i.e. in the recipe code have a section that looks for a node additional config and appends it if it exists, otherwise don't)

On 7 October 2015 at 06:36, Fabien Delpierre < " target="_blank"> > wrote:

Generally you would try to use an existing grouping like a chef environment, role, or policy (if you are using any of those). For single node edits you would do it directly via `knife node edit`. For things that are between the scope of a role and environment, https://github.com/poise/poise-appenv can be a solution.

Good to know about knife node edit. Wouldn't any change be overridden at the next chef-client run, though?

I guess I ought to look into policies, too. I've never used them but I'm not finding much documentation about them. Are we talking about the new-ish Policyfile feature? That I can find documentation about.

Does this help?

https://docs.chef.io/dsl_recipe.html#tag-tagged-untag

It'll get me started at least, thanks!

No. Nodes can receive attributes by having a role with attributes in a run list, in which case attributes are used from the role and/or by specifying an environment when Chef is run, in which case attributes are used from the environment. You can also set them in a recipe, which applies the attributes to the node object itself.

I was including that when I mentioned "editing the run list" -- of course that works but if I have multiple nodes that use the same set of roles/recipes and I edit one of those roles or recipes, all of them will be affected, which I may not want.

knife node edit does seem like it might help, but I'm concerned that the change wouldn't persist past a chef-client run.

As an example I have a recipe which installs a Newrelic agent if a certain attribute is set to true. In the production Chef environment I set the attribute so that all production nodes have this. If I want to use newrelic for a machine outside of production I can set that attribute on the individual node object instead, which could be in any environment.

So that makes sense if you have a recipe that's designed to look for that attribute, but that still seems like it wouldn't accomplish what one might do with Puppet's Hiera.

To use a concrete example, again with attaching YourKit to a JVM process -- like I mentioned, Hiera can aggregate multiple hashes or arrays spread between multiple sources into a single attribute.

For example, in one YAML file I could have:

foo::java_opts: "-Xms2g -Xmx2g"

And in another:

foo::java_opts: "-agentpath:/opt/yjp/bin/linux-x86-64/libyjpagent.so"

Then I could invoke this foo::java_opts in a recipe or a template (e.g. for an init script) and Hiera would combine them into one so it produces an init script might read: java -Xms2g -Xmx2g -agentpath:/opt/yjp/bin/linux-x86-64/libyjpagent.so

When I'm done with YourKit, I can just delete the YAML file that contains those bits and I never have to touch the nodes or the recipe since it only looks for what's in that java_opts attribute and spits it back out.

While so far it doesn't seem like this would be possible in Chef, it does seem like tags would help, if accounted for within a recipe, e.g.:

node.default['foo']['bar'] = false

if tagged?('bar')

  ruby_block 'enable_bar' do

    block do

      node['foo']['bar'] = true

    end

  end

end

if node['foo']['bar'] == true

  (do unspeakable things)

end

On Tue, Oct 6, 2015 at 10:23 PM, Noah Kantrowitz < " target="_blank"> > wrote:

On Oct 6, 2015, at 1:18 PM, Fabien Delpierre < " target="_blank"> > wrote:

> Hello folks,
> I'm a user of both Puppet and Chef, I'm more familiar with and prefer the latter overall, but am required to use the former at work. Recently I was toying with the idea of moving to Chef, although it's probably not a realistic option, but it raised a few interesting questions.
> While Puppet and Chef do roughly the same thing, they do it in slightly different ways, and Puppet has something in particular that Chef doesn't have, which is Hiera.
>
> If you're not familiar with Hiera, it's a simple way to apply settings to any number of your servers (from a single node to an entire infrastructure of thousands), you define the hierarchy of settings yourself -- in a sense, it's kind of like being able to customize Chef's attribute precedence and having a single environment attached to all your nodes. The link above explains it a lot better than I can.
>
> Anyway, I was wondering how one might deal with losing Hiera when moving from Puppet to Chef. It seems that you could achieve similar results with a mix of cookbooks, roles and environments, like everything else, but at the cost of ending up with a lot more of them than you'd normally have.
>
> I guess a different way I might ask this is:
> Imagine I have a group of servers, all configured the same way (same run list, same environment), and I need to change something on just one of them. A common scenario in my environment is having to attach YourKit to a JVM process.
> With Puppet/Hiera, I'd just add a two-line YAML file with the same name as that one server's FQDN, and when I run Puppet, that YAML file would be read at compile time and the config change applied without affecting the other nodes.
> With Chef, I'd have to modify the node's run list or take its environment file, make a copy of it, modify the copy and assign that copied environment to the node instead of the normal env file, lest I affect the other servers in the same group.
>
> Hiera is also capable of aggregating data from multiple sources into a single hash or array to be applied to a node during a Puppet agent run.
>
> Those are things that I never missed for as long as I used Chef, but now that I know they're out there, I'm wondering how I would handle things without Hiera.
>
> So in short, I was wondering if anybody has thoughts on the matter. Obviously it helps if you have some experience with both tools. I'm far from being a Chef expert so it's possible I'm missing something. Any input is appreciated. Thanks!
> Fabien

Generally you would try to use an existing grouping like a chef environment, role, or policy (if you are using any of those). For single node edits you would do it directly via `knife node edit`. For things that are between the scope of a role and environment, https://github.com/poise/poise-appenv can be a solution.

--Noah