[chef] Re: Re: Re: CHEF-3580: Do you keep node artifacts in source control?

[Bryan McLellan < >]

On Sat, Nov 3, 2012 at 7:23 PM, Mike 
<
 >
 wrote:
> I'm guessing by the lack of response to this message, not too many
> others are doing this either? It seems like there might be a use case
> for it, but I haven't thought of one yet.

I think there's a natural progression that most self-taught systems
administrators go through in regard to our server's identity, myself
included. We usually start off with a couple servers and we give them
somewhat random names that we like. Then as we get more we come up
with naming schemes like roman gods or transformers. We're able to
remember these names well and we can remember that mercury is our smtp
and anti-spam server. Eventually we have so many servers we just want
them all named by function, and then later adding location to the
hostname or a subdomain. In the post-automation days, there's now a
camp of people who prefer to name servers a unique random identifier,
and convey their purpose and location in metadata (and perhaps an
automated DNS name for convenience).

There's more than a couple folks out there with a limited number of
servers who still consider a server a "unique snowflake" and manage
its JSON representation as the source of truth about it. Back to the
other side of the coin, when I worked solely in operations at Opscode,
we kept a "run book" that listed each type of server and the knife
command to re-create it (given our git repository), which doubled as a
nice bit of a DR plan. Servers were meant to be thrown away and
resources were treated as a commodity.

On Sat, Nov 3, 2012 at 7:45 PM, Andrea Campi
<
 >
 wrote:
> I'm not sure I understand #3… fully expanding the run list, i.e. saving to
> the node the list of recipes that happen to appear on the run list, if we
> were to expand roles right now?
> That doesn't sound terribly useful, it will be out of date as soon as any
> role is edited.
> But I'm probably wrong and you meant something else.

Some folks who re-create nodes from json regularly as a source of
truth, rather than rebuilding the server, find that their search-based
recipes then begin to fail because the 'roles' and 'recipes' attribute
is not populated and many of their roles are children of the roles
listed on the server. Nothing prevents knife from doing this when it
creates the node object. This is CHEF-3528, btw.

On Sat, Nov 3, 2012 at 8:31 PM, Daniel DeLeo 
<
 >
 wrote:
> There's some context missing here. In Chef 11, Node objects internally store
> default and override attributes from roles and environments separately from
> attributes from cookbooks. These attributes are applied when the run_list is
> expanded (`Node#expand!`). Therefore, it's possible for knife, when creating
> or editing a node, to expand the run_list, setting the automatic
> node[:roles] and node[:recipes] attributes along with the attributes sourced
> from roles and environments. In the case of editing a node, attributes from
> cookbooks would be lost until you run chef-client on that node.
>
> This could be combined with option #4, so that normal attributes and
> automatic attributes on the node are retained, but default and override are
> replaced.

Right, which is relevant to #3. I was generally hoping to get more
detailed workflow use cases from those who store node objects in their
repositories though.

Bryan