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