How does the master repo stuff work?

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

I've been looking at Gianni's master repo stuff and am not sure I  
understand how it works so I have some questions.

1. If you deploy into the "local" config store is there any way this  
can result in activity in the master or cluster stores?  I would  
expect not but I haven't been completely able to convince myself of  
this.

2. If you deploy into the "master" config store can this result in  
activity in the local config store?  Again I'd expect not.

3. Does the wadi clustering builder have anything to do with which  
repos an app gets installed into?  Again I'd expect not.

4. Does the normal local attribute manager serve as attribute manager  
and persistent configuration list for the master and cluster repos?   
If not where do gbean customizations go for these repos?

5. After you've installed an app into the master repo, with say 3  
servers in the cluster or farm, and you shut down all the servers,  
what happens when you restart them?
a. one of the non-master servers before the master server
b. the master server
c. the other non-master server after the master.

Do you have to do anything to get the apps running on all servers?

Something else I was wondering about was possibly installing configs  
via the plugin installer gbean which has a configured target repo  
rather than directly into a config store.  This would provide  
transitive dependency download features from the plugin system that  
don't appear to be present in the current "direct to config store"  
approach.  I imagine this would require all configs to have at least  
a minimal geronimo-plugin.xml.... I'm thinking of adding this in  
during deployment if its missing.

This is a really nice feature!
thanks
david jencks

Re: How does the master repo stuff work?

[Gianny Damour <gi...@optusnet.com.au>]

On 21/12/2007, at 11:26 AM, David Jencks wrote:

> I've been looking at Gianni's master repo stuff and am not sure I  
> understand how it works so I have some questions.
>
> 1. If you deploy into the "local" config store is there any way  
> this can result in activity in the master or cluster stores?  I  
> would expect not but I haven't been completely able to convince  
> myself of this.
You are correct.

>
> 2. If you deploy into the "master" config store can this result in  
> activity in the local config store?  Again I'd expect not.
You are correct.

>
> 3. Does the wadi clustering builder have anything to do with which  
> repos an app gets installed into?  Again I'd expect not.
You are correct.

>
> 4. Does the normal local attribute manager serve as attribute  
> manager and persistent configuration list for the master and  
> cluster repos?  If not where do gbean customizations go for these  
> repos?

The GBean configurations for these configuration stores are in  
plugins/clustering/clustering/src/main/plan/plan.xml. Two new  
configuration stores are defined there:
1. MasterConfigurationStore: it relies on a Maven2Repository rooted  
at master-configuration/. When a configuration is installed into this  
MCS, it is also installed into the ClusterStore defined by the nodes  
declared by the cluster configuration. By default, the cluster  
configuration declares the current instance as a (local) cluster  
member. This is achieved by the NodeInfo GBean. In other words, out- 
of-the-box, when a configuration is installed into the MCS, it is  
also installed into the ClusterStore of this Geronimo instance.
2. ClusterStore: it relies on a Maven2Repository rooted at cluster- 
repository/. This configuration store is not intended to be directly  
used by end-users. Although, they can directly interact with this  
repo if need be.

These two configuration stores are used by the standard  
ConfigurationManager. Hence configurations loaded from these stores  
are altered by the default local attribute manager.

>
> 5. After you've installed an app into the master repo, with say 3  
> servers in the cluster or farm, and you shut down all the servers,  
> what happens when you restart them?
> a. one of the non-master servers before the master server
> b. the master server
> c. the other non-master server after the master.
>
> Do you have to do anything to get the apps running on all servers?

Let's assume that the configuration configId/artifactId/2.0/car is  
distributed to the master configuration store of server MASTER. Two  
servers are defined in the cluster: SERVER1 and SERVER2. In the case  
of a successful distribution:
* MASTER defines the configuration configId/artifactId_G_MASTER/2.0/ 
car, _G_MASTER for short
* SERVER1 and SERVER2 contain the configuration configId/artifactId/ 
2.0/car

To start configId/artifactId/2.0/car on SERVER1 and SERVER2, you need  
to start _G_MASTER on MASTER. Conversely, to stop it on SERVER1 and  
SERVER2, you need to stop t_G_MASTER on MASTER.

By default, _G_MASTER starts successfully even if SERVER1 or SERVER2  
are down upon start-up. This can be changed by setting the attribute  
BasicClusterConfigurationController.GBEAN_ATTR_IGNORE_START_CONF_FAIL_UP 
ON_START to false. In this case, _G_MASTER fails to start when  
SERVER1 or SERVER2 are down upon start-up.

MASTER acts as a kind of administration server. SERVER1 and SERVER2  
are "standard" servers and they can not become master (they do not  
know about _G_MASTER).


>
> Something else I was wondering about was possibly installing  
> configs via the plugin installer gbean which has a configured  
> target repo rather than directly into a config store.  This would  
> provide transitive dependency download features from the plugin  
> system that don't appear to be present in the current "direct to  
> config store" approach.  I imagine this would require all configs  
> to have at least a minimal geronimo-plugin.xml.... I'm thinking of  
> adding this in during deployment if its missing.
If you prefer to install configurations directly into a repository  
instead of going systematically through a config store, then the  
above design will no longer work. Having said that, it is possible to  
refactor it so that clustered deployment is handled at the repository  
level instead of the config store level. Let me know if you want me  
to work on this refacto.

Thanks,
Gianny


>
> This is a really nice feature!
> thanks
> david jencks
>