geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell E Glaue <>
Subject Re: Pulling Geronimo Configuration
Date Tue, 10 Feb 2009 21:52:02 GMT
David Jencks wrote:
> On Feb 10, 2009, at 8:09 AM, Chance Yeoman wrote:
>> Hello All,
>> I am interested in setting up geronimo installations that can pull
>> installed plugins and their dependencies exclusively from a repository
>> within a master geronimo server.  I hope to eventually have an
>> automated process allowing cluster members to poll a cluster-specific
>> geronimo server repository for available, locally uninstalled
>> plugins.  My goal is to be able to more easily manage geographically
>> separated cluster members and to quickly add or reinitialize nodes.
>> I've been having trouble getting started as I receive HTTP 401
>> responses when installing remote plugins using the admin interface,
>> even with security turned off on the maven-repo URL.  I can list the
>> contents of the remote server's repository, but not install plugins.
> That's pretty odd.  Can you show the urls being used?  You should be
> able to check that it's working with a browser.
>> My question is:  Is using the GeronimoAsMavenServlet even the correct
>> approach to pull-based configuration?  How have others implemented
>> configuration pulling?  Any advice would be greatly appreciated.
> If you use a geronimo server as the plugin repo then
> GeronimoAsMavenServlet is the correct approach.  However, if I were you
> I would give significant consideration to using nexus as the plugin
> repo.  I think you will have a much easier time integrating this with a
> reasonable build/qa process.  In particular, if you build the plugins
> using maven with the car-maven-plugin, you can set the distribution
> management repos to be the nexus server and have mvn deploy or mvn
> release make the plugin available to the appropriate production servers.

For satisfying this scenario, how does nexus compare to Archiva, or Artifactory?


> I hope you are also aware of the plugin-based clustering/farming support
> that may provide the features you need for easy rollout to mutliple
> servers.  If the existing features there don't exactly match your needs
> please work with us to improve this.  For instance IIUC since you
> indicate your cluster members are geographically separate the current
> multicast discovery of cluster members may not work for you... however
> changing this to a hardcoded set of servers should be pretty easy.  Or
> perhaps you want a hybrid approach where a bunch of multicast-connected
> sub-clusters aggregate to a controller.

I think the desire is to pull down the artifacts, initiated from the end
geronimo server. So if Geronimo starts up, it can go to the central Maven repo
and see if it needs to pull down anything for configuration.

The plugin-based farming, from my understanding, does the opposite. The central
server pushes out the new artifacts to the end web servers. And perhaps this
introduces a few possibly undesired circumstances:

1. Centrally pushed out, all servers receive the updates at one time, not
staggering the updates. Unless you put the servers into multiple groups so that
each group can receive updates at different times. But that is more administration.
2. If a server is offline when the push-out occurs, it is out of date when it
comes back online. Some kind of re-sync has to happen.

If the end geronimo server does a pull on start-up, then it will always be in
sync at run time. If we know what triggers the pull, an administrator can
program this into a distributed command (like Rio, or RHN Satellite command) to
tell the server to sync itself.


> thanks
> david jencks
>> Thank you,
>> Chance

View raw message