[chef] Re: Re: Re: Re: Re: Re: Re: Where to keep your <node>.json files?

[Jay Feldblum < >]

E.g., roles named "mysql-pair-1", "mysql-pair-2", "mysql-pair-3", "mysql-pair-4", etc., that are all essentially identical to each other but have the effect of allowing you to set up multiple mysql pairs. You don't need every single pair in source control, if they are all essentially the same. You might have a "mysql-pair" role which is included in each of the above, and that might be in source control.

On Mon, Apr 23, 2012 at 1:12 PM, Torben Knerr < " target="_blank"> > wrote:

Am 23.04.2012 18:48 schrieb "Jay Feldblum" < " target="_blank"> >:

>
> In the sphere of applications, we often have a codebase and a database. Only the code is stored in source control. None of the data is stored in source control, but we safeguard the data by taking frequent backups.
>
> One approach to using Chef, an approach paralleling applications, is as follows. Cookbooks are always code. Nodes and data-bags are always data. Some roles and environments qualify as code and some qualify as data; this varies from role to role and from environment to environment. Keep cookbooks and the code-ish roles and environments in source control; write code-ish roles and environments in Ruby. Keep node and data-bag data, along with the data-ish roles and environments, out of source control and left to the database; write data-ish roles and environments in JSON. To safeguard the data, take frequent backups of the database.
>

Can you give an example of code-ish vs. data-ish roles/environments/databags?

For me all of them qualify as "code" because they are represented as text and have the benefit that they can be easily version controlled, diffed and merged.

> What are people's thoughts on this way of using Chef?
>
> On Mon, Apr 23, 2012 at 12:31 PM, Juanje Ojeda Croissier < " target="_blank"> > wrote:
>>
>> Hi, Torben
>>
>> I think Spiceweasel could be a good idea to track all those changes:
>> http://wiki.opscode.com/display/chef/Spiceweasel
>>
>> Still it doesn't sync with your real infrastructure, but it is easy to
>> keep updated and is a good picture of your infrastructure-as-code.
>>
>> Cheers
>>
>> 2012/4/23 Torben Knerr < " target="_blank"> >:
>> > @AJ: how do you keep track of modifications to nodes, e.g. who added a new
>> > role or cookbook? Does Chef Server keep track of that?
>> >
>> > I was thinking that infrastructure-as-code wise one would keep the nodes in
>> > source control as well, as I would do for databags (and I see good reasons
>> > for doing that). Is this just a matter of taste or did I miss something?
>> >
>> > Cheers,
>> > Torben
>> >
>> > Am 23.04.2012 10:59 schrieb "AJ Christensen" < " target="_blank"> >:
>> >
>> >> I don't keep these. We only store them for backups when deleting
>> >> nodes, in the event that some data required for recovery is persisted
>> >> to node data.
>> >>
>> >> I wouldn't recommend the overhead of ensuring nodes are synchronized
>> >> from server to disk and back, but perhaps a tool could be built for it
>> >> (jenkins?)
>> >>
>> >> Embrace chaos, destroy nodes regularly -- build for failure.
>> >>
>> >> --AJ
>> >>
>> >> 2012/4/23 Motiejus Jakštys < " target="_blank"> >:
>> >> > On Mon, Apr 23, 2012 at 07:36, Torben Knerr < " target="_blank"> > wrote:
>> >> >> Ohai Chefs,
>> >> >>
>> >> >> But where do you keep these files? I was considering to put them under
>> >> >> chef-repo/nodes as the chef-repo git repo seems to be the right place
>> >> >> for
>> >> >> me. But since there is no such directory in the default chef-repo
>> >> >> structure
>> >> >> I was wondering if you guys know a better place for it?
>> >> >
>> >> > Well, I am using this directory for this purpose.
>> >> >
>> >> > --
>> >> > Motiejus Jakštys
>>
>>
>>
>> --
>> Juanje
>>
>> http://about.me/juanje
>
>