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 Wed, 11 Feb 2009 15:41:02 GMT
David Jencks wrote:
> On Feb 10, 2009, at 1:52 PM, Russell E Glaue wrote:
>> 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?
>> Archiva:
>> Artifactory:
> I only have experience with nexus and it's worked great for me.  I'm not
> thrilled with the license.  I haven't actually looked but have a strong
> impression that it has a lot more/better features than the older managers.
>>> 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.
> Your understanding is incomplete.  With plugin based farming the actual
> artifacts are pulled by each cluster member from the repository.
>> 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.
> Plugin based farming does pretty much this administration step.  The
> admin server keeps (in a db) plugins, plugin lists, clusters and
> plugin-list to plugin and cluster to plugin list associations.  It
> listens on a multicast address.  When a cluster member starts up it
> starts a heartbeat ping on that multicast address.  When the admin
> server recognizes a new cluster member it sends it a list of all the
> plugins that are supposed to be installed on it.  The cluster member
> then installs all the missing plugins on the list.
> If you don't like multicast you have to figure out some other way for
> the cluster members to find the admin server, such as by telling it. 
> Then when the admin server fails and you have to move it you need a way
> to tell all the cluster members to look elsewhere.  I know multicast is
> often frowned on but I couldn't think of a plausible alternative that
> seemed like it would actually work.  If you have any ideas I'd love to
> hear them.

Multicast is a good option to have available.
But we will probably have 40 Geronimo Installs, with perhaps 120+ Geronimo
instances, and distributed over separated LANS. Another option to multicast
would be nice.

Have you considered:

Rio -
All application deployed services and Rio itself is managable using JMX, with
notification support that includes an elegant peer-to-peer event model, allowing
interested consumers to be notified of application and management specific
events related to SLA enforcement, application deployment and service availability.

Sun Jini = Apache River -
River could use some help to move forward. Perhaps backed by Geronimo it might
get more interest.

> If you don't have any need for dynamic plugin administration but are
> happy to kill, reinstall, and restart a cluster member whenever the
> plugins change then you could do something pretty easily with gshell to
> start the server and install a list of plugins on it.... you can script
> this very easily so you'd only be shipping a script to the cluster members.

Actually, the Rio project can do this very nicely, in a distributed fashion.
You can script it to install more plugins, and execute it remotely/centrally.
But we are more interested in a centrally managed system, which we could
"mirror" out the requirements.

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

View raw message