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. 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. > > 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 >> >
