On Feb 11, 2009, at 7:41 AM, Russell E Glaue wrote:
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: http://archiva.apache.org/
Artifactory: http://www.jfrog.org/products.php
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.
I agree, but I haven't figured out what it should be yet. For your
use would you consider multicast on each LAN with hardcoded
connections between them?
Have you considered:
Rio - https://rio.dev.java.net/overview.html
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 - http://incubator.apache.org/river/RIVER/index.html
River could use some help to move forward. Perhaps backed by
Geronimo it might
get more interest.
I have nothing against jini or leases but AFAIK the service discovery
in jini relies either on multicast or on configuring the location of
some "admin" server, which is basically what we already do. For our
purposes I don't see the need to pull in another entire infrastructure
framework. If you have more or different information I'd love to know
more.
thanks
david jencks
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.
-RG
thanks
david jencks
-RG
thanks
david jencks
Thank you,
Chance
