4

i would be greatfull for help. I do not understand at all, how should i manage the Node data locally with my Git versioning system?

Exceprt from the Chef Documentation: http://wiki.opscode.com/display/chef/Nodes

knife node create foobar


{
    "normal": {
    },
    "name": "foobar",
    "override": {
    },
    "default": {
    },
    "json_class": "Chef::Node",
    "automatic": {
    },
    "run_list": [
       "recipe[zsh]",
       "role[webserver]"
    ],
    "chef_type": "node"
}

I have understood, I can manage this data on the server via knife over the editor!!. And there seem to be a command line option to the local chef-client (most likely -j JSON_ATTRIBS). => But chef-client runs locally and I need to upload the data to the server and then these node-attributes need to be pushed to the client. this is the only viable solution in an larger environment

But how to upload this data with knife? It seems there is no option for this? (only the option with the editor in knife seems to be present?)

Thanks Francois

2 Answers2

3

In Chef, the node is the authority. The best practice is to use knife bootstrap to get a system set up to run chef and integrate it with the Chef server.

The majority of the node attribute data is generated dynamically by the node when chef-client runs, where it uses ohai to discover information about itself. Other data can come from cookbooks and roles. Your cookbooks and roles should certainly be stored in your version control repository, in what is typically called the Chef Repository.

The main reason to store nodes locally is to capture their run lists. We recommend that you have a runbook document in your repository (like a README :)) that describes what kinds of servers you have and what their roles are.

jtimberman
  • 7,587
  • 2
  • 34
  • 42
1

I am currently thinking on how to keep track of changes to node run_list in repository. And the only thing that comes to my mind is to create a role for every node with the same name as the node. For example:

  1. We have 3 servers with hostnames: alpha, bob, charlie.
  2. We create 3 role-files in our roles folder: alpha.rb, bob.rb, charlie.rb
  3. We provide name, description, run_list in every file as if they are ordinary roles.
  4. Create run_lists for nodes that contain only the role with respective name.

And whenever we need to change the run_list we change the role and run_list stays the same.

Draco Ater
  • 357
  • 3
  • 12