geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: GBeans: Saving Changes
Date Tue, 26 Jul 2005 18:40:56 GMT
I really like this model and explanation and wonder just how soon we 
can make it a reality.

Last fall I thought we needed the ability to add gbeans to running 
configurations so you could add datasources, queues, etc to the server 
while you were getting ready to deploy an app, using an admin console 
(in fact an earlier version of the one just donated by IBM).

However, I think there's a better way to do this, namely, instead of 
adding bits to the app server to make the environment ready for the 
app, add bits of app server to the application so it brings what it 
needs along with itself.  Right now we can do this with plain gbeans  
in  all components (such as for security, corba, and web connectors), 
and resource adapters in app clients.  I'm planning the ability to add 
at least entire resource adapter configurations into other module 
types, and considering adding the ability to deploy additional complete 
j2ee modules just using the vendor plan.

I can imagine a bit of a ui that analyzes the configurations present in 
a server (i.e. a bunch of deployed configurations) and your application 
and shows you what is unresolved in the application, and guides you 
through either adding more prebuild configs to your server or adding 
additional stuff into your application so everything is pre-resolved 
before you try to deploy for the first time.

I think with this point of view and possibly with such tools most of 
the need to add gbeans to running configurations goes away.  As for the 
question of changing and saving gbean attributes in a running 
configuration, I'm not sure what to think.  It seems like an 
interpreted vs compiled language debate.  Right now our "compiler" is 
decidedly inconvenient for a rapid change cycle: I'm not sure how much 
faster it would need to get before it seemed like a more reasonable 
alternative to live changes.

thanks
david jencks

On Jul 25, 2005, at 7:09 PM, Jeremy Boynes wrote:

> I'd ask you to set aside traditional thinking and try this out for a 
> bit.
>
> When you write code, you edit a couple of source files, compile it, 
> fix the typos, build a jar, test it, decide its good enough and commit 
> the change. After doing this a few times you decide its good enough 
> and do a release, taking the jar file you built and saving for 
> posterity. You then do it all over again.
>
> If you're doing this with Maven, it spells out the difference between 
> the jar you are working with (a SNAPSHOT) and the jar you release 
> (something with a version number).
>
> Sound familiar?
>
> In a large production environment you do the same kind of thing with 
> system configurations. You set up a system the way you want, check 
> that it works, beat the snot out of it (aka stress testing or 
> benchmarking), see how/when it falls over, tweak the config and repeat 
> until it you're happy, then document it, have someone else try the 
> change in your staging environment, check it still works, then beg the 
> change control board to let you move it to production at 3AM on a 
> Sunday morning. You then cross your fingers and hope it really works.
>
> A bit different from changing things on a desktop machine or the box 
> that runs the family website, but not unrealistic and the problem the 
> architecture was trying to simplify.
>
> [[ to avoid a disgression, is Geronimo ready for this? Who knows; in 
> the end the people doing such things factor in the risks associated 
> with any software no matter how mature and they will make up their own 
> minds ]]
>
> The idea behind the configuration bundles is that they are pre-wired 
> sets of closely coupled components that co-ordinate to perform a 
> specific task. A single bundle is *not* meant to represent the entire 
> system assembly - the current o/a/g/Server is an abberation caused by 
> problems in the classloader model (described elsewhere) not example of 
> "best practice."
>
> The purpose of a bundle is to allow a knowledgable person to, for 
> example, pre-wire a web container in a way that allows other people to 
> use it just by defining a few characteristics. So, for example, 
> someone can go to a repository and find, for example, a pre-wired 
> version of a Jetty bundle pre-configured for 100 concurrent users at 
> 95% static content with a typical dynamic reponse time of 500ms when 
> running on an Acme-4000 Linux machine.
>
> So why does this need to be immutable? Because if you are pulling 
> these things from a catalog then you need to know that you're going to 
> get what you expect and not some version that someone happened to 
> tweak but just forgot to change the name.
>
> It would be like having several jar files out there called 
> log4j-1.2.8.jar that were actually different - a recipe for chaos. BTW 
> one reason bundles are JAR files is because it's dead easy to sign 
> them so that you can tell if they have been tweaked.
>
> Now, just as in the code development example I gave at the top, these 
> kind of pre-packaged bundles are also going to go through a 
> development process. One reason we didn't version stamp the configIds 
> in the current assembly is that until now all our configurations have 
> really been in development and it didn't make sense to be dealing with 
> new versions all the time. It probably would have been clearer to id 
> them as e.g. o/a/g/Server/1.0-SNAPSHOT but I guess that's water under 
> the bridge now.
>
> So, in an ideal world, your user below would just pick a suitable 
> pre-built bundle out of some repo and be happy with what it does. If 
> it doesn't quite do what they want or nothing suitable can be found, 
> they start by building and tweaking my/web/Container/1.0-SNAPSHOT, 
> iterate it a few times and then finalize on my/web/Container/1.0.
>
> The problem is identical to a developer not filling up their Maven 
> repo with trivially different versions of a jar they are working on 
> (which is why Maven has SNAPSHOTs in the first place).
>
> To pick a bad analogy, we're trying to do with server configuration 
> what Maven did for builds. No, I don't mean trying to make it slow and 
> take forever to start. We're trying to simplify the administration 
> process by allowing a admin to choose from a re-usable set of 
> pre-optimized bundles rather than having to do it all by hand, in the 
> same way Maven uses plugins to replace manually created ant scripts.
>
> It's different. It's unusual. It takes some getting used to.
> But it might just work.
>
> --
> Jeremy
>
> Aaron Mulder wrote:
>> 	For my part, I'm not convinced that it makes sense for 
>> configurations to be immutable.  I think the export/import feature 
>> would be nice -- "I finally got my web container configured 'just 
>> right', now let me export it and load it into my cluster of 30 
>> boxes".  I wouldn't even mind giving each configuration a unique hash 
>> or something such that we could eventually down the road add a 
>> feature where you export two related configurations, and one refers 
>> to that specific build of the other.  Or even having an immutable 
>> flag on a configuration such that once you've marked one as immutable 
>> it refuses to change in the future.
>> 	But to tell me that properties of a configuration shouldn't ever
>> be changed, or that GBeans shouldn't be added or removed at runtime 
>> and we
>> should create new child configurations instead... unless I'm
>> misunderstanding you, that just doesn't work for me.  I can't imagine
>> someone customizing their web container and then after a few revs 
>> they try
>> to load or unload or export it and discover that they now have
>> configurations "Server", "Server HTTP v1..v5" "Server HTTPS v1..v3"  
>> "Server AJP v1 & v2" "Server Keystore v1..v4" "Server accept thread 
>> pool
>> v1" "Server JSP Compiler v1..v3" "Server request log v1..v5", and so 
>> on.  Much better IMHO to let them alter the "Server" configuration to 
>> their
>> heart's content, then let them export it or flag it as locked if they 
>> want
>> to preserve a snapshot of that state.
>> Thanks,
>> 	Aaron
>> On Mon, 25 Jul 2005, Jeremy Boynes wrote:
>>> Configuration bundles are meant to be immutable so you shouldn't be 
>>> adding things to them at runtime. Think of them as being similar to 
>>> library jars or other maven artifacts - things would get very 
>>> confusing if you started adding classes into them as part of a 
>>> build. This allows the configuration to be identified by its ID in 
>>> the same way the artifact id identifies a dependency to maven.
>>>
>>> Configuration bundles have attributes (currently modeled by exposing 
>>> the GBeans they contain which is problematic) which pertain to the 
>>> location in which they are being used. The *default* values for 
>>> those attributes are contained inside the bundle; the instance value 
>>> is set by the environment.
>>>
>>> There are some implementation issues in Geronimo today (short cuts 
>>> taken for expediency) which obscure some of the subtleties of this 
>>> model. Some of these relate to classloading (the issues on the 
>>> packaging thread), others relate to GBean persistence.
>>>
>>> I'll give a couple of examples which I hope highlight a couple of 
>>> the issues.
>>>
>>> The first anti-pattern is that configuration ids are not unique - we 
>>> reuse them for different configurations. For example, although 
>>> Tomcat and Jetty based servers are quite different we use the same 
>>> "unique" id (org/apache/geronimo/Server) for both. We also reuse ids 
>>> across versions so it is impossible to tell if an application 
>>> deployed against org/apache/geronimo/Server was built using M1, M2, 
>>> M3 or HEAD. It is like only ever compiling against SNAPSHOT 
>>> dependencies.
>>>
>>> Secondly, if configurations are immutable then you should not be 
>>> able to add GBeans to them at runtime (that would be mutating them). 
>>> So how do you add a network connector? The simplest model is to 
>>> separate the web container from its connectors and build them as 
>>> separate bundles (one for the container, one for each of the 
>>> connectors); if you want to add a new connector you add a new 
>>> instance of e.g. the HTTPS bundle.
>>>
>>> Finally, there is the issue of instance properties - things in the 
>>> environment of where a configuration is being used that need to 
>>> override the default properties that is has. For example, the 
>>> default for the HTTP connector bundle might be to listen on port 
>>> 8080 but on this server here it needs to be changed to be 8888. 
>>> Right now we do this by mutating the configuration installed in the 
>>> store which is problematic. Instead it would be better to associate 
>>> the state with the runtime and, after the bundle was loaded but 
>>> before it was started, inject those local values into it.
>>>
>>> There's a fine line between when you want to override values on a 
>>> per instance basis and when you want to define a new configuration 
>>> for with those values as defaults. There's no right solution to that 
>>> but I think the type of installation plays into it:
>>> * for a desktop development environment or single server installation
>>>   then you are better just overriding properties as needed
>>> * for a clustered environment or large scale deployment then you are
>>>   better defining reusable bundles that can be easily moved 
>>> where/when
>>>   they are required
>>>
>>> As Geronimo starts being considered for larger installations let's 
>>> not forget what the original config system was designed to do.
>>>
>>> --
>>> Jeremy
>>>
>


Mime
View raw message