Re: Versioned configuration
Steve Loughran <[email protected]>
| Newsgroups | gmane.comp.java.smartfrog.user,gmane.comp.java.smartfrog.devel |
|---|---|
| Message-ID | <[email protected]> |
Itamar Shtull-Trauring wrote: > Hi, > > I'm looking at designing a system which may end up being built on > SmartFrog. There are various applications, policies for running them, > and data flows that go between various applications, all of which need > to be versioned. For example, "Host A runs a Foo v1.2 server that > require DataFormat v3.6 which it gets from Bar v2.4 running on Host B." > > Actions might involve: > 1. adding a new version to the list of available versions for a program > (or a data flow, etc.) > 2. Changing config for specific machine to use new version. This should > figure out using dependency tree what else needs upgrading, and upgrade > those if possible. E.g. "Foo v1.2 requires the Foo1.2 rpm to be > installed so do that, which then cause Bar on same machne which depends > on that RPM to be upgraded as well", or "Foo v1.2 requires Dataflow v1.3 > instead of v1.2, but new config doesn't set up this so complain." > 3. Run the upgrade, allowing manual intervention if possible. > > Parts of this are out of the scope of what SmartFrog can do, I think. > I'm still reading documentation and getting ready to start playing with > it though, so I am unclear which parts would be a good fit. > > I guess my main question is, could the configuration language be > extensible to support the concept of versioning and dependencies on > versions, and would it be possible to easily add new configuration at > runtime? > yes, it can and should be version aware. One problem with versioning is that you soon end up trying to describe the rules "version(A)>1.2 and version(A) < 1.6.2 or (version(B)=2.0 and version (A)>1.5)" or similar. That is, it's not always enough to declare minimum version that works. I want to do a repository component for java jars that is compatible with the maven repositories; you will be able to say you need version 2.6.2 of xerces, 3.8.1 of junit, etc, and they will be downloaded (cached), validated, etc. You wont have full version logic, but you can at least control versions of libraries just by updating your declaration of JAR file versions (and SHA1 digests, for security). will this do? -steve ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click