Re: Smartfrog - too much power?

Sorry, first time on this list and caught out by the Reply-To header.
Keeping it on the list...

Hi Steve,

Thanks for the detailed response.

I definitely think that SmartFrog is the way to go for us, rather than
a bunch of shell scripts. I think it will scale better if the company
grows as we hope it will.

<snip/>

> Hello James
>
> Deploying WAR files and bringing up tomcat/jboss is a reasonable use for
> SmartFrog, especially if you have both test and production systems.
> Because you are going to end up run a lot deployment a lot of during
> that development process.
>
> Now, in theory, WAR files are self-contained packages that can be
> deployed simply by copying them to the app server. But that isnt true.
> There's the setting up of the app server -the GC options, the DNS-lookup
> timeout options, the need to get the JDBC drivers up in the classpath to
> the right place that JDBC doesnt throw class not found exceptions, and
> there is the late-binding configuration of the different servers. The
> JDBC URLs and passwords, the path to the network filestore, etc. There's
> the database itself, be it derby, mysql, mssql or oracle: it needs to be
> installed, set up with the tables, and permissions -and with the users
> and passwords that the WAR file is expecting. Its this app server setup
> and system configuration that is the pain in bringing up a new system.
>
> Right now most of this stuff is done with incomplete instructions -the
> bigger the project, the longer the instructions. This doesnt scale, and
> if something happens in the wrong order, you are in trouble, left with a
> system in an inconsistent state, having to roll back, or, if its a
> virtual machine, deleting the image and starting again. At least with VM
> images you can make one image and share it, but you then need to
> reconfigure the VMs with different JDBC urls, else whenever someone does
> a clean test they end up scrubbing the database. This is particularly
> likely with MSSQL by the way, as the DB is located using a flat
> namesserver across the entire organisation. Just because the production
> DB is in San Jose, doesnt mean that a test machine in Portland wont bind
> to the first database called "AppDB" in the company.

Been there, got the T-Shirt and the furrow in my head from scratching
it so much.

> My recommendation is learn the tool during those pauses in the long
> builds and test runs, and start using it for simple parts of the problem
> (deploy-by-copy, testing) to get happy with it before you go in to
> production with it, where you have to study the security bits of the
> documentation to see how to keep the operations team happy.

But I already have plans for those pauses!

http://xkcd.com/303/

I've got a week's holiday now with the SmartFrog docs for some light
reading (along with the Erlang book, Scala docs and some other fun
stuff). I'll see how I go.

Cheers,

James

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/