• “Infrastructure” turns out to be the hardest thing to explain when discussing automation, yet is the most critical to understand. In this context, Infrastructure isn’t anything physical (or virtualized) like servers or networks. Instead, what we’re talking about is all the “stuff” that is configured across machines to enable an application or service.

    

  In practice, “stuff” translates to operating system baselines, kernel settings, disk mounts, OS user accounts, directories, symlinks, software installations, configuration files, running processes, etc.

• Cloud is API oriented, everything you see in cloud is ulitmately programmable.

   

  Virtualization is the foundation of Cloud but virtualization is not Cloud by itself. It certainly enables many of the things we talk about when we talk Cloud but it is not necessary sufficient to be a cloud. Google app engine is a cloud that does not incorporate virtualization. One of the reasons that virtualization is great is because you can automate the procurement of new boxes.

• Chef's Data Bags are incredibly useful. They are a very nice way to feed lists of users to multiple cookbooks. Think of them as global variables for your chef-server. One the benefits of data bags is that they allow you to separate your corporate information from your cookbooks. Thus, making it easier for Chef users to open-source their cookbooks. Puppet has extlookup but that is quite a bit more limited than data bags. It looks like Puppet maybe getting something similar to data bags with Hiera.
• It was easy to get started with Puppet, but things became more complicated with time. With Chef I am having the opposite experience. Again, the single biggest drawback to Chef is that it has a steeper learning curve than Puppet.
• Don't buy the argument "Chef requires you to be a programmer, Puppet doesn't."

1 more annotation...

• I could(and still can) see the promise in the tools it provides the user with but it’s just so difficult to work with especially coming from a Cfengine background(and lack of programming experience) that for my first iteration I dumbed it down a whole bunch, making the logic very Cfengine like, at least as much as I could. I didn’t use any data bags, any attributes, no templates, nothing like that. I had (and still have) a very hard time finding usable examples for many things in Chef. They have a big repository of sample cookbooks – but to me for the most part those are not usable, because while examples they don’t go into details as to specifically, literally what each line of code does
• Where the opscode folks and I seem to part ways is our priorities. Their priority is to turn the system management into code and automate it to the point where it scales to a million systems
• I came up with a new saying a few months ago after dealing with Chef. If it’s not friends with sed, awk and grep then it’s not friends with me. Chef, being very developer-centric uses a lot of JSON to store and manage it’s various configurations. JSON is very much not friendly to sed, awk and grep, and so it frustrates me greatly whenever I have to deal with it
• The standard way of Chef bootstrap is a sort of push approach, where there is a management agent that waits for a system to be provisioned, then ssh’s to the system and runs a bunch of stuff. I wanted a pull approach, where the system is provisioned and boots up and configures itself.
• With regards on how I used to do things with Cfengine, it was simpler than Chef. Cfengine operates more on trust than Chef. Chef uses public/private keys to authenticate systems, and these keys have to be in the right place in order for a system to get registered. This is good for untrusted networks, like public clouds(ugh). Cfengine works more on trust, where you can (or at least I did) assign network ranges where the IPs are trusted, and a new system could just register itself without any special configuration.
• t’s really well done, but even now that a lot of the hard work was done by him, in a very chef-like way I constantly struggle to add new stuff in, or to change existing things because it’s so dynamic. I see a value for something – where is it coming from? is it from the node? environment ? data bag? attribute? something else?
• I see the same with Chef. It’s a powerful tool but it’s just not there yet with regards to usability,
• I dare say I have spent FAR more time trying to work with Chef on these hard things (understanding the concepts, code etc) than just flat out doing it by hand the old fashioned way.

6 more annotations...

• Once upon a time, all systems were configured manually. This strategy is the easiest to understand, but the hardest one to execute. It typically happens in development and small production environments where configuration details are small enough to fit into a wiki or spreadsheet. As a network’s size and scope increases, management efforts became massive, time consuming, and prone to human error. Details end up in the heads of a few key people and reproducibility is abysmal. This is obviously unsustainable.

• Unlike CFEngine, where policy is copied and evaluated on the edges, Puppet clients connect to the Puppet server where configuration is determined based on a certificate CN. A catalog of serialized configuration data is shipped back to the client for execution. This catalog is computed based on the contents of the manifests stored on the server, as well as a collection of facts collected from the clients. Puppet facts, like CFEngine hard classes, are discoverable things about a node such as OS version, hostname, kernel version, network information, etc.

• When and Where Order Matters

     

   Recently I have been hearing the resurfacing of an old debate: whether order matters in the execution of configuration management policy.
• Unless you are trained in management, it feels wrong to simply declare what you want, without explaining how to get it. In the words of Rich Hickey, engineers are trained to `complect' WHAT we want with HOW we get it -- muddling things up.

• Operation
  • Connecting to guest systems
    • No connection to the guest systems possible via the Administration Tool.
    • Possible connection to the guest systems console mode only.
    • Possible connection to the guest systems in graphics mode only (like VNC), even in safe mode.

    Not Evaluated
  • Backup and Restore
    • Saving images
      • No backup possible.
      • Backup and restore cold images is possible via the tool but not hot.
      • Hot backup and restore images is possible via the tool.

      Not Evaluated
    • Synchronized backups
      • No feature of backup / restore synchronized multiple virtual machines.
      • Ability to backup / restore cold-synchronized multiple virtual machines, but not hot.
      • Ability to backup / restore synchronized hot multiple virtual machines.

      Not Evaluated
  • Updates
    • No possibility of updating systems via the tool.
    • Features updated virtual images managed by the solution.
    • Features updating images and virtual machines managed by the physical solution.

    Not Evaluated
  • Automation of complex
    • No possibility to automate complex business operations: no scripting or workflow.
    • Ability to automate complex business operations via scripting and scheduling simple.
    • Ability to automate complex business operations via scripting and the workflow management.

    Not Evaluated
  • Search
• Supervision
  • Physical Systems
    • No supervision of physical systems.
    • Supervision of physical systems resources (CPU, RAM, disk space, ...).
    • Supervision of physical systems resources (CPU, RAM, disk space, ...), material elements (eg temperature and fan) or power consumption.

    Not Evaluated
  • Virtual objects
    • No supervision systems virtual objects (images, networks, storage).
    • Supervision systems of some virtual objects managed by the solution (images, networks or storage).
    • Supervision systems of all virtual objects managed by the solution (images, networks or storage).

    Not Evaluated
  • Notifications
    • No notification mechanism is available.
    • Ability to configure the trigger notification on a limited number of events and via the email channel only.
    • Ability to configure the trigger for notification of many events, with conditions and via multiple communication channels (email, SMS ...).

    Not Evaluated
  • Logging and reporting
    • No logging capability, Historian or reporting is available.
    • Existence of logging functionality but limited to a technical level and can not be used for purposes of resporting.
    • The tool offers logging capabilities and advanced reporting (statistics, graphs, historical ...).

    Not Evaluated
  • Integration

• • Cfengine is the only one that can control nearly any
    aspect of host configuration using the configuration language without much additional programming.

  • The translation of the applied role depends on ”facts” collected by ”facter” and the resource provider
    interpretation of facts. Cfengine is not intended to be explicit in the same way, but rather just specify
    intended behavior based on context provided by classes, regardless of nodename.

• I hate that both these tools are dependent on ruby. I love ruby for what it is but it really is not ideal for this type of work. Ruby is only supported on 32bit platforms by the own admission of the developers (all other platforms are best effort), ruby has no real stable versioning ie 1.9.1 is not compatible with 1.9.2 even though they say it is, . I’m in the process of a chef deployment and it’s been a nightmare getting ruby synced up between different OSes. God help us when we need to go to a newer distro and will have to do this ruby dance all over again. I pushed for CFengine because it stays out of the way of the OS but didn’t win, I really wish I pushed harder.

• Open source software assessment methodologies

• but find useful open source packages can be trickier to master.