Issue - configuring the binary distribution

[Jeff Genender <jg...@savoirtech.com>]

Hi,

I want to open up a discussion for binary distribution.

Currently we are not packaging the plans in the binary distribution. 
This will likely cause some issues with the users as it will be 
inevitable that the configurations will need changing.  Examples will be 
SSL certificates (i.e. keyfiles)...to have an AJP connector or 
not...have a Realm that covers the entire server, or even Virtual Hosts. 
   These are all typically server level configurations and much less at 
an application specific level. I would say most users who want to use 
Geronimo in production *will* be having a need to change the 
configuration, and I think rebuilding from source is not acceptable.

We need to make the ability to alter these objects and easily change the 
config without the need to download the entire source base.

I think this is a critical path issue that we need to address before a 
1.0 release as it will cause huge complaints IMHO.

My .02...I think that packaging the plans with the assembly (and maybe a 
maven script or other to easily enable a redeployment (cli?)) is a short 
term solution and something we need to come to terms with, but we should 
also discuss our long term goals around this.

Comments?

Jeff

Re: Issue - configuring the binary distribution

[Jeremy Boynes <jb...@apache.org>]

Jeff Genender wrote:
> 
> My .02...I think that packaging the plans with the assembly (and maybe a 
> maven script or other to easily enable a redeployment (cli?)) is a short 
> term solution and something we need to come to terms with, but we should 
> also discuss our long term goals around this.
> 

I think including the plans is useful both for re-configuration and as 
samples/templates for people to use. We did this with Gluecode's 
redistribution BTW.

--
Jeremy

Re: Issue - configuring the binary distribution

[David Jencks <da...@yahoo.com>]

This is a big topic....
On Aug 1, 2005, at 10:15 AM, Jeff Genender wrote:

> Hi,
>
> I want to open up a discussion for binary distribution.
>
> Currently we are not packaging the plans in the binary distribution. 
> This will likely cause some issues with the users as it will be 
> inevitable that the configurations will need changing.  Examples will 
> be SSL certificates (i.e. keyfiles)...to have an AJP connector or 
> not...have a Realm that covers the entire server, or even Virtual 
> Hosts.   These are all typically server level configurations and much 
> less at an application specific level. I would say most users who want 
> to use Geronimo in production *will* be having a need to change the 
> configuration, and I think rebuilding from source is not acceptable.
>
> We need to make the ability to alter these objects and easily change 
> the config without the need to download the entire source base.
>
> I think this is a critical path issue that we need to address before a 
> 1.0 release as it will cause huge complaints IMHO.
>
> My .02...I think that packaging the plans with the assembly (and maybe 
> a maven script or other to easily enable a redeployment (cli?)) is a 
> short term solution and something we need to come to terms with, but 
> we should also discuss our long term goals around this.

I think some customization is supported by the izpack deployer, 
although I haven't tried it.  Maybe it needs more advertisement

I think we should try to get the copies  of the source plans and the 
instructions/scripts for reassembling the server into M5.

  Longer term, I would like to promote a revolution in how people 
approach configuration and deployment, based on the  idea of 
configuring the bits of server you need around your application or 
group of applications.

There are several parts to this.

First, breaking up our current monolithic plans into lots of 
module-specific configurations with limited "change points" and 
supplying prebuilt configurations with appropriate defaults.

Second supplying some way to define which parts of a configuration can 
be edited "post deployment" and which can't.  I think there is a 
proposal about "manageable attributes" but don't remember it clearly.  
Also supplying some way of actually editing these, such as perhaps 
putting them in a text or xml configuration file.  To me this is very 
different from allowing arbitrary edits of a plan after it's built into 
a configuration.  I  don't think we should allow adding more gbeans for 
instance.

Third, promoting the idea of starting from the application requirements 
and configuring the application by adding server bits to it to support 
the service levels the app requires.  For instance, if your web app 
needs a special ssl keystore and a particular thread pool size, make it 
easy to add a jetty (or tomcat) connector configured appropriately to 
the application: then any server you deploy it on will get the correct 
stuff it needs to run the app.  If you are running a family of related 
applications, you would build a configuration with the connector 
support you need, and associate it somehow with the set of 
applications, so that when you distributed the app configuration(s) to 
a particular server instance, the appropriate connector support would 
come along with it.

I think it may take us a while to get this usable but I think it will 
be worth it.

thanks
david jencks

>
> Comments?
>
> Jeff
>

Re: Issue - configuring the binary distribution

["Alan D. Cabrera" <li...@toolazydogs.com>]

On 8/1/2005 4:15 PM, David Jencks wrote:

>
> On Aug 1, 2005, at 4:08 PM, Jeff Genender wrote:
>
>>
>>
>> Aaron Mulder wrote:
>>
>>>     I want to provide the necessary features in the web console to
>>> handle the stuff that a user is likely to want to change.
>>
>>
>> Would this include the ability to add GBeans as well as configure 
>> existing ones?
>
>
> So far I am really against adding gbeans to existing configurations.  
> I don't have a problem with the web console generating entirely new 
> configurations, although I doubt it is all that useful.  My opinions 
> can always be argued against :-)

I feel the same way.


Regards,
Alan

Re: Issue - configuring the binary distribution

["Alan D. Cabrera" <li...@toolazydogs.com>]

On 8/1/2005 4:30 PM, Aaron Mulder wrote:

>On Mon, 1 Aug 2005, David Jencks wrote:
>  
>
>>So far I am really against adding gbeans to existing configurations.  I 
>>don't have a problem with the web console generating entirely new 
>>configurations, although I doubt it is all that useful.  My opinions 
>>can always be argued against :-)
>>    
>>
>
>	It seems like Jeremy and I came to a mutually satisfactory
>conclusion where (and I'm summarizing in haste) altering the configuration
>(including adding/removing) would be possible, but it would also be
>possible to flag specific configurations as not alterable and give them a
>specific version number and all.  I think that's the best of both worlds
>-- if you want it editable, you use the standard behavior.  If you want it
>locked down so you can guarantee that a deployment performed on machine X
>will work when exported and imported into machine Y, then you freeze the
>configurations you're dealing with and build machines X and Y from those.
>
>	I will apply a little elbow grease to getting David J on board 
>this week.  :)
>  
>
This sounds interesting to me.


Regards,
Alan

Re: Issue - configuring the binary distribution

[Aaron Mulder <am...@alumni.princeton.edu>]

On Mon, 1 Aug 2005, David Jencks wrote:
> So far I am really against adding gbeans to existing configurations.  I 
> don't have a problem with the web console generating entirely new 
> configurations, although I doubt it is all that useful.  My opinions 
> can always be argued against :-)

	It seems like Jeremy and I came to a mutually satisfactory
conclusion where (and I'm summarizing in haste) altering the configuration
(including adding/removing) would be possible, but it would also be
possible to flag specific configurations as not alterable and give them a
specific version number and all.  I think that's the best of both worlds
-- if you want it editable, you use the standard behavior.  If you want it
locked down so you can guarantee that a deployment performed on machine X
will work when exported and imported into machine Y, then you freeze the
configurations you're dealing with and build machines X and Y from those.

	I will apply a little elbow grease to getting David J on board 
this week.  :)

Aaron

> >> I further would
> >> like to have that implemented under the covers by a management API 
> >> that
> >> can be invoked outside of the web console.  I further have the idea 
> >> that
> >> to change stuff while the server is "not running" (including parts 
> >> that
> >> barf on startup) we could load the server into a 
> >> loaded-but-not-started
> >> mode and then use the management API against that -- presumably with 
> >> some
> >> kind of command line tool, that's much more limited that the web 
> >> console
> >> (at least, the minimum requirements are ports and perhaps SSL
> >> configuration, because those are the things that actually prevent you 
> >> from
> >> starting the server to run the web console or a generic JMX or JSR-77 
> >> client).
> >> 	All that aside, the installer package leaves copies of the
> >> (customized) plans it uses.  Perhaps the ZIP/GZ package should do the
> >> same.
> >> Aaron
> >> On Mon, 1 Aug 2005, Jeff Genender wrote:
> >>> Hi,
> >>>
> >>> I want to open up a discussion for binary distribution.
> >>>
> >>> Currently we are not packaging the plans in the binary distribution. 
> >>> This will likely cause some issues with the users as it will be 
> >>> inevitable that the configurations will need changing.  Examples 
> >>> will be SSL certificates (i.e. keyfiles)...to have an AJP connector 
> >>> or not...have a Realm that covers the entire server, or even Virtual 
> >>> Hosts.   These are all typically server level configurations and 
> >>> much less at an application specific level. I would say most users 
> >>> who want to use Geronimo in production *will* be having a need to 
> >>> change the configuration, and I think rebuilding from source is not 
> >>> acceptable.
> >>>
> >>> We need to make the ability to alter these objects and easily change 
> >>> the config without the need to download the entire source base.
> >>>
> >>> I think this is a critical path issue that we need to address before 
> >>> a 1.0 release as it will cause huge complaints IMHO.
> >>>
> >>> My .02...I think that packaging the plans with the assembly (and 
> >>> maybe a maven script or other to easily enable a redeployment 
> >>> (cli?)) is a short term solution and something we need to come to 
> >>> terms with, but we should also discuss our long term goals around 
> >>> this.
> >>>
> >>> Comments?
> >>>
> >>> Jeff
> >>>
> >
> 
> 

Re: Issue - configuring the binary distribution

[Jeff Genender <jg...@savoirtech.com>]

David Jencks wrote:
> 
> On Aug 1, 2005, at 4:08 PM, Jeff Genender wrote:
> 
>>
>>
>> Aaron Mulder wrote:
>>
>>>     I want to provide the necessary features in the web console to
>>> handle the stuff that a user is likely to want to change.
>>
>>
>> Would this include the ability to add GBeans as well as configure 
>> existing ones?
> 
> 
> So far I am really against adding gbeans to existing configurations.  I 
> don't have a problem with the web console generating entirely new 
> configurations, although I doubt it is all that useful.  My opinions can 
> always be argued against :-)

This will be a problem with the web stuff.  Particularly with virtual 
hosts, valves, or custom realms (which many people use).  This would 
require the existing configurations to change by adding the particular 
object/gbean. How about an AJP connector for those that want to 
front-end a web server in fron of the servlet container at a system wide 
level?

Also, what about custom login modules and domains that are server wide?

Jeff

> 
> david jencks
> 
>>
>>> I further would
>>> like to have that implemented under the covers by a management API that
>>> can be invoked outside of the web console.  I further have the idea that
>>> to change stuff while the server is "not running" (including parts that
>>> barf on startup) we could load the server into a loaded-but-not-started
>>> mode and then use the management API against that -- presumably with 
>>> some
>>> kind of command line tool, that's much more limited that the web console
>>> (at least, the minimum requirements are ports and perhaps SSL
>>> configuration, because those are the things that actually prevent you 
>>> from
>>> starting the server to run the web console or a generic JMX or JSR-77 
>>> client).
>>>     All that aside, the installer package leaves copies of the
>>> (customized) plans it uses.  Perhaps the ZIP/GZ package should do the
>>> same.
>>> Aaron
>>> On Mon, 1 Aug 2005, Jeff Genender wrote:
>>>
>>>> Hi,
>>>>
>>>> I want to open up a discussion for binary distribution.
>>>>
>>>> Currently we are not packaging the plans in the binary distribution. 
>>>> This will likely cause some issues with the users as it will be 
>>>> inevitable that the configurations will need changing.  Examples 
>>>> will be SSL certificates (i.e. keyfiles)...to have an AJP connector 
>>>> or not...have a Realm that covers the entire server, or even Virtual 
>>>> Hosts.   These are all typically server level configurations and 
>>>> much less at an application specific level. I would say most users 
>>>> who want to use Geronimo in production *will* be having a need to 
>>>> change the configuration, and I think rebuilding from source is not 
>>>> acceptable.
>>>>
>>>> We need to make the ability to alter these objects and easily change 
>>>> the config without the need to download the entire source base.
>>>>
>>>> I think this is a critical path issue that we need to address before 
>>>> a 1.0 release as it will cause huge complaints IMHO.
>>>>
>>>> My .02...I think that packaging the plans with the assembly (and 
>>>> maybe a maven script or other to easily enable a redeployment 
>>>> (cli?)) is a short term solution and something we need to come to 
>>>> terms with, but we should also discuss our long term goals around this.
>>>>
>>>> Comments?
>>>>
>>>> Jeff
>>>>
>>

Re: Issue - configuring the binary distribution

[David Jencks <dj...@gluecode.com>]

On Aug 1, 2005, at 4:08 PM, Jeff Genender wrote:

>
>
> Aaron Mulder wrote:
>> 	I want to provide the necessary features in the web console to
>> handle the stuff that a user is likely to want to change.
>
> Would this include the ability to add GBeans as well as configure 
> existing ones?

So far I am really against adding gbeans to existing configurations.  I 
don't have a problem with the web console generating entirely new 
configurations, although I doubt it is all that useful.  My opinions 
can always be argued against :-)

david jencks

>
>> I further would
>> like to have that implemented under the covers by a management API 
>> that
>> can be invoked outside of the web console.  I further have the idea 
>> that
>> to change stuff while the server is "not running" (including parts 
>> that
>> barf on startup) we could load the server into a 
>> loaded-but-not-started
>> mode and then use the management API against that -- presumably with 
>> some
>> kind of command line tool, that's much more limited that the web 
>> console
>> (at least, the minimum requirements are ports and perhaps SSL
>> configuration, because those are the things that actually prevent you 
>> from
>> starting the server to run the web console or a generic JMX or JSR-77 
>> client).
>> 	All that aside, the installer package leaves copies of the
>> (customized) plans it uses.  Perhaps the ZIP/GZ package should do the
>> same.
>> Aaron
>> On Mon, 1 Aug 2005, Jeff Genender wrote:
>>> Hi,
>>>
>>> I want to open up a discussion for binary distribution.
>>>
>>> Currently we are not packaging the plans in the binary distribution. 
>>> This will likely cause some issues with the users as it will be 
>>> inevitable that the configurations will need changing.  Examples 
>>> will be SSL certificates (i.e. keyfiles)...to have an AJP connector 
>>> or not...have a Realm that covers the entire server, or even Virtual 
>>> Hosts.   These are all typically server level configurations and 
>>> much less at an application specific level. I would say most users 
>>> who want to use Geronimo in production *will* be having a need to 
>>> change the configuration, and I think rebuilding from source is not 
>>> acceptable.
>>>
>>> We need to make the ability to alter these objects and easily change 
>>> the config without the need to download the entire source base.
>>>
>>> I think this is a critical path issue that we need to address before 
>>> a 1.0 release as it will cause huge complaints IMHO.
>>>
>>> My .02...I think that packaging the plans with the assembly (and 
>>> maybe a maven script or other to easily enable a redeployment 
>>> (cli?)) is a short term solution and something we need to come to 
>>> terms with, but we should also discuss our long term goals around 
>>> this.
>>>
>>> Comments?
>>>
>>> Jeff
>>>
>

Re: Issue - configuring the binary distribution

[Jeff Genender <jg...@savoirtech.com>]

Aaron Mulder wrote:
> 	I want to provide the necessary features in the web console to
> handle the stuff that a user is likely to want to change.  

Would this include the ability to add GBeans as well as configure 
existing ones?

> I further would
> like to have that implemented under the covers by a management API that
> can be invoked outside of the web console.  I further have the idea that
> to change stuff while the server is "not running" (including parts that
> barf on startup) we could load the server into a loaded-but-not-started
> mode and then use the management API against that -- presumably with some
> kind of command line tool, that's much more limited that the web console
> (at least, the minimum requirements are ports and perhaps SSL
> configuration, because those are the things that actually prevent you from
> starting the server to run the web console or a generic JMX or JSR-77 
> client).
> 
> 	All that aside, the installer package leaves copies of the
> (customized) plans it uses.  Perhaps the ZIP/GZ package should do the
> same.
> 
> Aaron
> 
> On Mon, 1 Aug 2005, Jeff Genender wrote:
> 
>>Hi,
>>
>>I want to open up a discussion for binary distribution.
>>
>>Currently we are not packaging the plans in the binary distribution. 
>>This will likely cause some issues with the users as it will be 
>>inevitable that the configurations will need changing.  Examples will be 
>>SSL certificates (i.e. keyfiles)...to have an AJP connector or 
>>not...have a Realm that covers the entire server, or even Virtual Hosts. 
>>   These are all typically server level configurations and much less at 
>>an application specific level. I would say most users who want to use 
>>Geronimo in production *will* be having a need to change the 
>>configuration, and I think rebuilding from source is not acceptable.
>>
>>We need to make the ability to alter these objects and easily change the 
>>config without the need to download the entire source base.
>>
>>I think this is a critical path issue that we need to address before a 
>>1.0 release as it will cause huge complaints IMHO.
>>
>>My .02...I think that packaging the plans with the assembly (and maybe a 
>>maven script or other to easily enable a redeployment (cli?)) is a short 
>>term solution and something we need to come to terms with, but we should 
>>also discuss our long term goals around this.
>>
>>Comments?
>>
>>Jeff
>>

Re: Issue - configuring the binary distribution

[Aaron Mulder <am...@alumni.princeton.edu>]

On Mon, 1 Aug 2005, Bruce Snyder wrote:
> At any rate, what I still don't understand is the desire to use a GUI
> for everything. Any type of UI can be developed if there's an API
> behind it.

	Sure, one of the reasons I'm keen on a nice management API.

> But what I don't agree with is the need to load the server into an
> unstarted state of some kind just to reconfigure it. Aaron stated
> previously that he has code to load the configs, change them and write
> them out again, correct? If I'm missing something, please explain this
> further.

	The GBean state is stored in a config store.  Without loading part 
of the server, you don't know where that config store is (file, database, 
which file, which database, etc.).  I mean, we currently only have one 
implementation (file) storing data in one place 
(GERONIMO_HOME/config-store) at the moment, but there's no guarantee that 
will always be true, and I think Jeremy strongly objected to hardcoding 
stuff to assume any single (config store implementation plus path).

	Anyway, once you have the config store loaded, you can access the
saved data for each Configuration.  That essentially contains the state
information for a bunch of GBeans for each Configuration.  You have two
options to actually read and update the GBean state.  One is to manually
deal with a whole bunch of Serialized junk, depending on specific
implementations of certain internals to translate that to usable data and
back.  The other is to just go ahead and start a kernel and its config
store and then load the GBeans from the config store, read and update
their properties, and then store them back to the config store again.  
That handles all the nitty gritty automatically and can't be foiled by 
changing implementations of various core services.

	But there are some subtleties here that could use more attention
-- I think Jeremy and/or David J dealt with all this when working on the
deployer stuff.  Right now I believe the server.jar contains the config
store information, and the deployer.jar has to contain the same config
store information, or else they won't work properly together.  There was
some talk about separating dependencies and things out of server.jar (to
avoid manifest class path entries for reasons that I can't recall), which
might make the initial server plan more accessible to deployer.jar and
also to whatever the management tool would use.  But for the moment, I
think they all would need to be built with the same expectations to work
correctly together.  Grr, really wish we could have this talk around a
whiteboard!  :)

Aaron

Re: Issue - configuring the binary distribution

[Bruce Snyder <br...@gmail.com>]

On 8/1/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:

>         I want to provide the necessary features in the web console to
> handle the stuff that a user is likely to want to change.  I further would
> like to have that implemented under the covers by a management API that
> can be invoked outside of the web console.  I further have the idea that
> to change stuff while the server is "not running" (including parts that
> barf on startup) we could load the server into a loaded-but-not-started
> mode and then use the management API against that -- presumably with some
> kind of command line tool, that's much more limited that the web console
> (at least, the minimum requirements are ports and perhaps SSL
> configuration, because those are the things that actually prevent you from
> starting the server to run the web console or a generic JMX or JSR-77
> client).

I'm glad to see this argument surface again as it's one that I tried
to promote a few weeks ago. I must say, I find it odd that most of my
ideas were shot down but are now appearing in the argument above and a
previous message about the management API. I'm truly puzzled by this.

At any rate, what I still don't understand is the desire to use a GUI
for everything. Any type of UI can be developed if there's an API
behind it. But what I don't agree with is the need to load the server
into an unstarted state of some kind just to reconfigure it. Aaron
stated previously that he has code to load the configs, change them
and write them out again, correct? If I'm missing something, please
explain this further.

Bruce 
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Re: Issue - configuring the binary distribution

[Aaron Mulder <am...@alumni.princeton.edu>]

	I want to provide the necessary features in the web console to
handle the stuff that a user is likely to want to change.  I further would
like to have that implemented under the covers by a management API that
can be invoked outside of the web console.  I further have the idea that
to change stuff while the server is "not running" (including parts that
barf on startup) we could load the server into a loaded-but-not-started
mode and then use the management API against that -- presumably with some
kind of command line tool, that's much more limited that the web console
(at least, the minimum requirements are ports and perhaps SSL
configuration, because those are the things that actually prevent you from
starting the server to run the web console or a generic JMX or JSR-77 
client).

	All that aside, the installer package leaves copies of the
(customized) plans it uses.  Perhaps the ZIP/GZ package should do the
same.

Aaron

On Mon, 1 Aug 2005, Jeff Genender wrote:
> Hi,
> 
> I want to open up a discussion for binary distribution.
> 
> Currently we are not packaging the plans in the binary distribution. 
> This will likely cause some issues with the users as it will be 
> inevitable that the configurations will need changing.  Examples will be 
> SSL certificates (i.e. keyfiles)...to have an AJP connector or 
> not...have a Realm that covers the entire server, or even Virtual Hosts. 
>    These are all typically server level configurations and much less at 
> an application specific level. I would say most users who want to use 
> Geronimo in production *will* be having a need to change the 
> configuration, and I think rebuilding from source is not acceptable.
> 
> We need to make the ability to alter these objects and easily change the 
> config without the need to download the entire source base.
> 
> I think this is a critical path issue that we need to address before a 
> 1.0 release as it will cause huge complaints IMHO.
> 
> My .02...I think that packaging the plans with the assembly (and maybe a 
> maven script or other to easily enable a redeployment (cli?)) is a short 
> term solution and something we need to come to terms with, but we should 
> also discuss our long term goals around this.
> 
> Comments?
> 
> Jeff
>