[CentOS] Spacewalk or Puppet?

[Karanbir Singh]

On 11/04/2009 12:15 PM, Marcus Moeller wrote:
> I am personally not that big fan of Puppet, as things are getting quite
> complex in large scenarios and as Puppet does not scale well (this has
> been improved in the latest version if you are using passenger instead
> of webrick).

Puppet is actually easier to scale beyond a few nodes than spacewalk is. 
Remember that the client->server model for puppet is optional. eg. One 
set of people I introduced puppet to use git as a policy distribution 
layer and run ~ 12k instances using puppet, with average delivery time 
being less than 4 minutes from released, with less than 10 min 
guaranteed for role/policy implementation on the designated nodes ( its 
a large hosing setup, we did these calculations just last weekend ).

> If you are willed to set up complex configurations with depends and
> variables, Puppet may be a good choice. In addition of Cobbler or
> TheForeman you will get provisioning functionality, too. IMHO you should
> also be familiar with Ruby, too.

I dont agree with either of the two, puppet is one package with ruby on 
the machine, how many dozens of thigns do you need to install for 
spacewalk ? What is the stability and maintenance loop like for each 
component ? And how many hoops do you need to jump through in order to 
get your app rollout linked into state management with spacewalk ? Try 
the same for puppet or even bcfg2 /chef/cfengine - its just a case of 
comparing apples and oranges. They dont do the same thing and they are 
both good to have, you just need to make up your mind what level you 
want to abstract at and how you want to split roles. Eg. Spacewalks's 
config policy management capabilities are about 3 generations behind 
what puppet is able to give you today.

> Spacewalk is one single tool for all Lifecycle Management task. It is
> capable of bare provisioning (using Cobbler integration),
> re-provisioning (using Koan), configuration management, errata
> generation and package management. It also scales quite well if you are
> using Oracle Standalone instead of XE. With PostgreSQL, a free database
> backend will be integrated in the near future.

I think you highlighted the main issues yourself - spacewalk does a fair 
bit of different things than puppet - the only real overlap is on config 
management ( which I prefer to call policy - since its a case of policy 
that defines the role of a specific box ). And at that puppet is way 
ahead of the capabilities of spacewalk.

The other massive win you can get from an integrated spacewalk/puppet 
deployment is the ability to stop running ssh and any remote access to a 
machine. Which in turn means that your spacewalk setup will have ( 
almost by force ) a good representation of the platform and the puppet 
manifests give you a fantastic view of the entire policy deployment 
across the entire infrastructure - just this is worth a lot when you 
have employee churn and/or need to consider platform re-factoring. And 
with a vcs to back up the puppet manifests, you get all the audit, track 
and management around that policy that you need.

btw, I also dont agree with the idea that using puppet needs knowledge 
of ruby - its like saying using cfengine needs knowledge of 'C' or using 
OpenOffice needs intricate knowledge of Java. On the other hand, Chef 
aims to be closely associated within ruby - and if you said that Chef 
needed a fair ruby mindset, I'd agree :)

- KB

PS: Your email client is broken. Its not preserving thread sanity.

-- 
Karanbir Singh
London, UK        | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219      | Yahoo IM: z00dax      | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc