[chef] Re: General questions about provision/kickstart!

["Eric G. Wolfe" < >]

Responses in-line

On 12/21/2011 4:25 AM, Sven Sternberger wrote:
> Hello!
>
> we are examine alternatives to our legacy CM infrastructure.
> I'm little bit puzzled about which parts chef plays.
Chef/Puppet plays the role of idempotent configuration in your post 
installation, and post deployment, phase.  In the cloud, Chef and Knife 
plugins may combine some of these steps with using cloud provider API 
calls, e.g. knife ec2, knife bootstrap.
1. Bootstrap node with JeOS (Just Enough OS)
2. Optional one-off configuration scripts in Kickstart or Preseed.
  - You may have single run tasks better handled with 
Kickstart/Preseed, like turning off unnecessary services on first boot.  
Maybe you need to turn some of those back on with Chef/Puppet, depending 
on a node's role.
3. Bootstrap (install) chef-client/puppet.
4. Configure node with Chef/Puppet.  Bring the node into its correct state.

Can you tell us a bit more about what role your existing CM 
infrastructure plays?  How are you provisioning systems with existing 
"legacy" solutions in place?
> I would look at cobbler vs. foreman for
> provisioning and Chef vs. puppet for CM. But is
> this correct? Could chef do the provisioning without
> cobbler/foreman? What is "best practice" to provision
> servers.
I use a central tftp/PXE server with Syslinux, gPXE, and Kickstart 
script components.  That is the "best" I can do, while still meeting 
organizational requirements.  Our requirements include the ability to 
pxechain separate PXE servers like RIS/WDS off of our central server.  
"Best practice" is a subjective term that may not apply to everyone. 
Chef complements our existing provisioning solution, while meeting all 
our requirements and not creating a bottle neck in the provisioning process.

We tried out Cobbler with Puppet, when both solutions were in early 
stages of development.  If I recall Cobbler was able to generate a 
default Puppet manifest for nodes, through the use of templates.  Which 
to be honest, was kind of neat, but did not seem to be that useful, 
because Cobbler was designed primarily for provisioning.  Maybe I am 
missing the point of that ability to integrate with a CM solution.  I 
want Puppet nodes managed by the Puppetmaster and Chef nodes managed by 
the chef-server.  I don't want, or need, Cobbler to manage my 
Puppet/Chef nodes in post deployment.  It looks like there is also some 
repo-syncing capabilities in Cobbler, but again Cobbler was not designed 
for upgrade management, in the same sense that Spacewalk fits that 
purpose.  I can't speak to how Cobbler or Foreman integrates with Chef.  
I may revisit Cobbler in the future for the repo-synch capabilities and 
see if it complements our existing patch management, and upgrade processes.

To answer your question, Chef can do the configuration without Cobbler 
or Foreman.  If there is a major problem with your existing "legacy CM 
infrastructure" that you are specifically trying to address, then look 
at what each solution offers and how it matches your requirements.  If 
your existing provisioning solution can bootstrap a Puppet or 
chef-client agent onto newly installed nodes with a simple post-install 
script, there is nothing incorrect with doing just that.
> We are mainly using Scientific Linux (RHEL-Clone) and
> a little bit ubuntu.
>
> Any help would be appreciated.
>
> regards
>
> sven