Brett Porter wrote:
Vincent Massol wrote:
I've used Maven in the past to do that and it worked very well. I'd
like to
understand better what alternatives you're suggesting?
Note for versioning: we have that by storing the config in the SCM.
I'm curious to know which tool you're using in the J2EE space for doing
"versioning and deployment". I don't know any.
My point was similar to Steve's. Yes, we can provide tools to help, but
I don't see us coming up with the grand unified theory of configuration
management. We used to store our configs in SCM and have some simple
server side tools (that a deployer could use, as developers certainly
weren't getting up in the middle of the night for releases :)
yeah,. they wake you when you get it wrong anyway. Although we have a
gui for managing a running (remote) system, ops people like command line
tools. Indeed, they like command line tools in Perl ;)
Note: I've also tried some other solution. One of them was to have a
configuration module in charge of generating the configuration for a
given
server and a given environment. A centralized configuration. It didn't
work
too well. It was too hard to keep it centralized. We didn't use any
tool. We
built our solution based on templates/velocity. I've had better
success with
a distributed configuration approach where each module is in charge of
generating its configuration per environment. But I'm interested in other
people's feedback on this!
Yes, I agree with this approach too. About the only time centralised
configuration might make sense is if you are talking about application
configuration via LDAP or a database, for example.
Here are some things I've done in the past
-war files that get their config from a per-hostname XML File in the
war. Lets you do one war, many servers. Ops cannot change things without
a rebuild, but it stops them doing changes that aint on SCM.
-LDAP. Another point of failure and config. Replication is good for scale.
-Database: no extra complexity if there is a db in it already.
-DNS. custom hostnames for boxes with different roles in the cluster.
If you look at what smartfrog does, it has the notion of
-components that configure things and move it through a lifecycle
-a language for describing the config that includes cross-referenced stuff
-runtimes that talk to each other using RMI over SSL.
-dynamic download of component implementation classes (with signed JARs)
-a component, Anubis, that does robust multicast coordination. you
need this manage things in clusters properly.
-the ability for things to add runtime data to the config graph., and
for that data to persist past the lifetimeof the component
-containers handling failures of their kids. lets you do workflow.
components that retry deploying with exponential backoff. and a bit of
jitter, etc. etc.
Runtime configuration management is a painful and complex beast. Believe
me. Build time generation of smartfrog descriptors might be something to
consider: creating the templates for other apps to handle. The problem
then becomes
-how to create the template
-how to deploy it
-maybe how to get runtime information back from the graph into maven
-how to undeploy everything afterwards.
-security
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
