[chef] Re: RE: Re: Baremetal Provisioning

[Maxime Brugidou < >]

Hi, we have a centos and debian image built from debirf that boots a minimal ram disk OS from PXE by default. The server pops up in chef automatically. Then we have some servers running fully diskless and others installed on-disk with an "os" cookbook capable of installing some Linux distro and even Windows server.

We should open source these I guess.

On Sep 4, 2013 6:49 PM, "Phillip Roberts" < "> > wrote:

Thank you Mr. Knowles and Mr. Pipes.

Seems like I had the right idea. Just wanted to make sure there wasn't some crazy knife plugin out there that does magic that I don't know about or something.

Appreciate your responses!!

O-H!! Go Bucks!!

Thanks Again,

Phillip Roberts | Sr. Linux Administrator
San Mateo | Ann Arbor | New York | London
O 734.922.7014 | C 614.423.9871 | www.MyBuys.com


-----Original Message-----
From: Jay Pipes [mailto: "> ]
Sent: Wednesday, September 04, 2013 12:19
To: ">
Subject: [chef] Re: Baremetal Provisioning

On 09/04/2013 11:54 AM, Phillip Roberts wrote:
> Does anyone have any good links or pointers to bare metal provisioning?
> I have done plenty of cloud based chef stuff, however, we want to now
> start managing all of our physical servers with chef as well. I am
> trying to replace as much of our build system as possible (ad hoc bash
> / perl scripts) for this provisioning. So I am looking for a good way
> to do this, I understand chef is not a PXE server, but just how far
> back in the tool chain can I go?
>
> My thoughts are serving up a kickstart file (since we are a RHEL /
> Cent based shop) that builds just enough of the OS in order to hand off to chef.
>
> Anyway, any pointers, or past presentations / links would be much
> appreciated.
>
> Thanks,

Hey there Phillip :)

We use Chef, Cobbler, and a small amount of Python glue code to provision our bare metal nodes and network devices (the ones that support modern OSs at least ;) -- nodes that run infrastructure services, nodes that run OpenStack API and support services, and OpenStack Compute worker nodes (boxen that provide tenant-facing compute capacity). Works very well.

We use Ubuntu 12.04 as our base netboot OS, with a simple preseed setup that implants our Chef validation keys on a vanilla barebones server OS install, and our Python glue code simply calls out to Cobbler and Chef to populate node attributes (from a set of YAML files we keep about the nodes in our deployment zones), power cycle or netboot nodes, and stuff like that.

All in all, I would say the most pain we've experienced in Chef land has probably been around configuring raw network interfaces for bonded NIC setups (we've found it virtually impossible to configure networking properly without having Chef reboot the server once -- restarting networking just doesn't work reliably) and around out-of-order Chef node attribute get/set issues... something that isn't helped by the myriad different precedence levels associated with attributes for nodes, roles, environments, etc. My advice: stick to the "application cookbook"
strategy (sometimes called "wrapper cookbook" strategy) versus putting any logic or much of anything in role definition files.

Best of luck, and Go Bucks! :)
-jay