I'm listening to this discussion and trying to make sense of it so that
I can understand how it will affect our users. Keep in mind that I'm
still grasping at the fundamentals of Geronimo and G-beans so this may
be off in the weeds (and for which I will apologize for right now).
As I think David Jencks mentioned earlier, are think there are
different types of configuration data? Can we list some of the
specific types of configuration items that we are talking about and
group them? Perhaps that can simplify the problem.
Here's my attempt:
First, there is "configuration" which affects the structure of the
solution itself (let's call it "solution configuration") ... such as
changing the access protocol, changing the J2EE container, changing the
security service, the persistent store, etc.... These are all changes
that have substantial impact on the nature and behavior of the server.
These are things that I would expect of somebody that is building a
complete solution to be concerned with and I don't think it would be a
problem if the changes were "maven-like" and required creating a new
bundle (ie. not hosted in the admin console for runtime changes).
Second, there is "configuration" which affects the behavior of the
solution but not the nature of it (let's call this "server
configuration"). These are more minor changes such as changing ports,
hostnames, thread pool sizes, etc... This is standard end user
configuration and items that I would expect an end user that is running
a solution to have to "tweak" on a regular basis. These are types of
configuration changes where I think it would be useful to be able to
export and then later import the configuration for another server and
that should be persisted apart from the Gbeans. This configuration may
even include the set of deployed applications for the server.
If we consider these items as being fundamentally different types of
configuration with different users then I think it might simplify the
problem. The "server configuration" changes should be available via
the admin console and should not impact any G-Bean configuration as I
understand it. The "solution configuration" would potentially affect
the creation of and dependencies between Gbeans and would not
necessarily require a WYSIWYG mechanism for change such as an admin
console. Of course there will always be items in the "gray" area that
are somewhere between these or may need to be changed by both types of
users. Items in the "gray" area could be addressed on an individual
basis such that it would not necessarily require mutable bundles (such
as by defining both HTTP and HTTPS connectors and enabling or disabling
as appropriate for the configuration).
One final question I'll toss out (and possibly show my ignorance ...
but at least I'll learn the answer :-) ) ... Aren't the applications
that are deployed themselves represented by Gbeans in the bundle and
therefore the bundle is already mutable in that sense? I read an
article in JAX that indicated this was the case (
http://jaxmag.com/itr/online_artikel/psecom,id,690,nodeid,147.html ).
Is that correct or was the author mistaken?
Aaron Mulder wrote:
We're making progress! :)
On Tue, 26 Jul 2005, Jeremy Boynes wrote:
First caveat - o/a/g/Server is too monolithic which is contributing
factor to these discussions. The reasons why this is a problem and how
to start to fix it have been discussed elsewhere.
True, though there are certain advantages too (like the ability to
start and stop all that stuff with one command). Anyway, that's another
topic.
Second caveat, change through the web console is one use case. It
applies to small installations (desktop, single server) but is less
applicable to larger installations, say with > 10 servers. It also does
not apply to "headless" servers which may not be running a web container
at all.
Agreed.
I have two I've given some thought to although they're not fully thought
out - but hey, we're brainstorming right?
Yes.
Of the two, I like option 5 more -- and more than all the
UUID-based options. I'm not sure the mutability needs to be reflected in
the configuration name, though -- couldn't we have non-name properties for
the version and mutability? That way the start/stop command would be the
same and so on. You would refer to a prerequisite by providing the name
and version range separately, and perhaps even indicating explicitly
whether you're willing to depend on a mutable version. If you provide
nothing but the name, that implies "any version will do".
I'd propose we add a tool that can export one or more
configurations named on the command line (or all current configs) and
optionally:
- mark them immutable
- assign them a specific version or UUID
- update any references between exported modules to use the new version
number or UUID
- include an explicit list of all their repository references if that's
at all possible (as even locking the configuration contents does not
prevent them from failing due to missing repository contents).
- sign the exported file(s)
Then we likewise need an import tool that can do whatever
name-based validation we want (perhaps prompt or automatically disable any
other configs with the same name and different version), make sure the
repository contains all the referenced libs, and load the configurations
into the config store.
Then the installer could offer a bit more flexibility, and let you
literally install with nothing but o/a/g/System (for a "slave" node), so
that you could then use the configuration import tool to get all the
(immutable or otherwise) content into that server.
We also need the kernel to be aware of Configurations to the level
that it can ensure a configuration is marked mutable when a change is made
to any GBean in the configuration.
Finally, I don't have a satisfactory answer to "what if you just
redeploy from a plan with different contents but the same name". It
doesn't seem all that different than making changes through the console,
except the kernel has no way to intercept that if the configuration was
marked immutable.
Aaron
Option 5: We have two different bundle types, mutable and immutable.
Mutable ones have a special ID, e.g. containing the word SNAPSHOT so
they can be clearly identified; immutable ones have a specific version
number e.g. o/a/g/Server/1.0-M5. Any structural modification of the
bundle, e.g. adding a GBean, changing a reference pattern etc. makes the
bundle mutable. We enhance the configuration manager so that it can
handle bundle version ranges so that bundle-to-bundle dependencies are
squishier than they are now.
So, when the deployer builds the application it could say "this
application expects a Jetty bundle with version between 1.0.1 and 1.0.5
or a SNAPSHOT." Modifications through the web console that require
strucutural change convert the config say o/a/g/Jetty-1.0.2 to
o/a/g/Jetty-1.0.2-SNAPSHOT; bundles built with a tolerance for
mutability will still run but ones that assume a release version won't.
For desktop and small installations we do a default assembly using
SNAPSHOT bundles; larger installations will probably build their own
assemblies using released versions only.
---
Option 6: We add a "local" bundle to the runtime that is used to hold
"stuff associated with this instance." This would be mutable and contain
GBeans associated with this instance e.g. edge components like network
listeners.
With this model, a second HTTP connector would be added to the "local"
bundle rather than o/a/g/Server or o/a/g/Jetty. Deployment does not
break for portable applications which only use components from named
bundles.
For this to work we will need to fix the classloader to provide the
import/export mechanism add will need to be able to add imports to the
"local" configuration at runtime. We need to be careful about adding
multiple GBeans that require classes from conflicting imports.
---
There may be the possibility of a combination of multiple options e.g.
mixing "local" bundles with SNAPSHOTs or UUIDs.
--
Jeremy
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
|
