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


Chronological Thread 
  • From: Tensibai < >
  • To: < >
  • Subject: [chef] Re: *** PROBABLY SPAM *** Re: Re: General questions about provision/kickstart!
  • Date: Thu, 22 Dec 2011 15:01:51 +0100

Le 22.12.2011 13:17, Sven Sternberger a écrit :

Hello!

On Wed, 2011-12-21 at 14:06 -0500, Eric G. Wolfe wrote:
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?
1. Register a host with our selfmade provisoning system
(http://www-it.desy.de/systems/services/wboom/). Mac,Ip and DHCP/PXE
template are also stored in an enterprise system (VitalQIP). The
data is stored in the AFS.

2. Depending on group assignment, hardware type and some flags the
provisioning system  creates kickstart files for all supported variants
of Scientificlinux and config files for pxelinux. 
The kickstart files brings an adjusted partition schema and extra
packages. In the post part we mount afs and start our legacy CM
(http://www-it.desy.de/systems/services/salad/)
The pxelinux config sets the os version to install.

3. Based on the data from the registration, we run in fixed intervals 
our CM (shellscripts).
These scripts get their parameter from the AFS and bring extra packages,
updates, nfs, setting root pw, automount config, access rights ...

What I'm still missing in all cobbler, forman, puppet, chef stuff is 
the  central place to register a host and store the meta data. It looks
like I have several places where a host has metadata. 
So for example I give a set of workgroup server from one department the
same partion scheme and I want for all workgroup server the same
automount configuration. The first setting is for cobbler, the second
for chef, but I have to configure it in cobbler and chef?

At this point we will have to code the glue between something like
foreman and chef (and it looks like the integration with puppet is
already there for free) 
or
we will configure chef with the metadata from our legacy system

regards!

sven

Well, as far as I know, the way to do it with chef is having a minimal os with a common partition scheme, and define recipes doing partionning on other parts of the disk and creating the automount conf accordingly.

It's more about having a minimal install, the rest of the machien configuration is maintained and enforced by chef.

The base install should not include too much things, as you will use chef to install /update packages/softwares on boxes after.

I use Altiris as deployment system, which takes care of installing the OS, chef-client, chef.rb and validation.pem. Then run chef-client once.

I usually set up the nodes roles manually after, but I'm working on REST calls to set the roles to the new node (really early stage for now)

 

 



Archive powered by MHonArc 2.6.16.

§