I actually work full time on complex system deployment, of which the
core runtime. SmartFrog, is LGPL-licensed and sourceforge hosted
(http://smartfrog.org/). If you want to know more, the latest slides are
http://people.apache.org/~stevel/slides/oscon.pdf
BTW, I have found this sentence in your OSCon PDF:
"Systems are composed of applications that are composed of components".
That's very cool as it matches almost exactly the directory structure I had
in mind. I called components modules but we could them components :-)
Components and modules both have so many meanings; 'things you deploy'
is another one.
Cool. I'll be reading this and checking out the smartfrog project. More
specifically I need to find out if the open source part of smartfrog is
enough to satisfy the needs for deploying a J2EE system or if it
requires
people to buy additional things.
to be honest, right now, there is no direct support in our code for
jboss or geronimo. I tried to persuade the geronimo people last week
that they need to think about it. But there is
-JMX control
-war deploy to jetty+tomcat
-a jboss component from Brazil to do
Ear support is on my todo list, Jboss being the obvious target. The goal
is to decouple configuring the app from the server, so you can switch
from app server provider just by changing an option in a deployment
descriptor and redeploying -or better yet, creating a new descriptor
that extends a base one for use on a different cluster. That todo list
is budy with core work related stuff, which is primarily dull Ws-* and
grid related things.
Cool. I wonder if there could be synergies with Cargo... It seems there is
potentially some overlap.
Cargo could even possibly be used internally by Smartfrog to
start/stop/deploy to containers as it already supports a big number of
containers... The opposite could be true so that Cargo could have an EL for
generating container configurations (ATM we have either a default config for
which users can configure important parameters such as ports, log levels,
security, etc) or a config provided by the user).
If it works in a world of signed jars, then yes, we could use it.
Another thing we like to add is liveness; that is every component
supports a health check that can be triggered in a walk down the graph
of deployed components. Some components do nothing but liveness, such as
one that probes for a web page and fails if the response is out of
range, the size too small or the content type wrong.
NB, there is no business model of paid-for-premium things. We are part
of a research lab. Once you have automated deployment to the extent that
you need 10 boxes + the option of 500 more for peak loads, then you have
the option of talking to the bit of HP that sells CPU time on demand.
But that is merely an option.
:-)
Incidentally, on the subject of testing, Vmware are now giving away free
vmware runtimes. This lets you test more deployments on a single host,
so even the developers can have multi-server deployments on their
laptops. slick.
Sounds great. I went to the vmware website and couldn't see any offer. Would
you have more detail?
http://www.vmware.com/products/player/
That said, it seems to me that there are maybe different levels:
- the poor man's solution which could be implemented using Maven. Again
this
is what I've done at several places and I know several others who have
done
the same successfully. I'm not saying this is the best, I'm just saying
that
it can work in some circumstances.
Oh I agree, it works just like shell scripts and ant or custom RPMs. The
problem is that you cannot easily transfer all the configuraton work
into a production system, so the only thing that gets carried over from
dev to staging to live systems is experience in debugging configuration
problems.
Sure. On some projects I had worked on we had retroactive loops where
configuration and tuning from production teams get reinjected into our SCM
so that next time we deliver a new version it's closer to the required
production config. But honestly the production teams I have seen we really
not at the level of doing something like what smartfrog does... Files were
edited and modified by hand, no version control, no recording of what was
done, etc...
Always the case, always the case.
Even small projects have repeated and different deployments. It just
doesnt hurt as much doing it by hand as it does on large scale 100+node
systems, where manual intervention is clearly impossible.
I'd be curious to understand more about how to use smartfrom with a build
system such as Ant or Maven. Where do you store smartfrog config files (in
the SCM? In some external repos? In a Maven remote repo? :-)).
When running with security turned on (as you really ought to do
everywhere :). the runtime only deploys descriptors that are in signed
JAR files. Our components stick their templates in the JAR files that
implement the components themselves. Apps that deploy can include them
in their own JARs or in custom things. Once I add security to the Ant
tasks I'll have to create JAR files on the fly from the inline descriptors.
We also have late binding info; you can get at properties of the JVM
Is there a sample application that I could check out from somewhere and run
on my machine to check how it all works?
Grab the latest release off the site -http://smartfrog.org/ . Start with
the tutorial. I dont think we have any out the box demo apps, but maybe
we should.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
