[Camps-users] Integration with related projects

[Davor Ocelic]

> Kickstart: Initially provisioning Red Hat Enterprise Linux servers the 
> same way each time. Basic stuff.
> 
> Puppet: System configuration management across the various tiers of the 
> application, and enforcing uniform access, configuration, and package sets 
> and updates.
> 
> Camps: Development environment management including handling the split 
> between version-controlled code and databases, a multi-developer and 
> multi-project scenario, and making development work accessible to business 
> people at all stages.

I'am working on something like this myself (complete install +
configuration + environment). My system is Debian-centric because
that's what I primarily need, but since configuration data is stored
in LDAP, generating i.e. redhat's kickstart configuration is just
a matter of reading ldap keys and putting them in format required by
kickstart.

After the installation is done, Puppet etc. do the part of the work
that goes beyond packages' options built in to its pre/post-install scripts.

> On another note, since Puppet and Capistrano are both written in Ruby, and 
> we've been contemplating rewriting Camps for version 4 anyway, I've been 
> thinking about whether it might make sense to write it in Ruby instead of 
> Perl. That would let us leverage any Puppet or Capistrano libraries that 
> would be useful, but it would also settle the question of which add-on 
> object system to use in Perl (standard blessed hashes? Moose? Coat?) since 
> Ruby's built-in object system would suffice and thus greatly reduce 
> external dependencies. (We'd see the same advantage with Python.)

I've taken a look at Camps' Perl code, and also I've been working on
Ruby projects for the past few months, and the 'niceness' of Ruby code
compared to Perl is becoming more and more obvious to me.
I've come to a point where I'm preferring Ruby over Perl any time.

Btw, we've been developing an application in Ruby 1.8, and hoping that
we'd be able to use Ruby 1.9 by the time the software is shipped
(problem were some library bindings not available in Ruby 1.9). Anyway,
long story short, we got it working on Ruby 1.9, and worth noting, 1.9
gives 4 to in some cases 20 times better performance over 1.8.

-doc