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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
