[jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

[Jason Greene]

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion

"To scope or not to scope (domain.xml)"

To view the discussion, visit: http://community.jboss.org/message/536382#536382

--------------------------------------------------------------
> Brian Stansberry wrote:
> 
> > Jason Greene wrote:
> > When you think about it, a server-group, and a cluster are really the same thing, the only difference is that the cluster has an additional set of services that a basic group does not.
> 
> Yes, but isn't the set of capabilities that a server has defined by its profile? We could say that defining a server as part of a cluster means that additional capabilities are added beyond what's in the profile. But then we are dividing the definition of a profile into two places. Also, exactly what capabilities should be added if a server is in a cluster is unclear

I think there is a definite overlap between the definition of a profile and the definition of a grouping. The only way I can see having both in domain.xml is to have the profile function as a template like you mention earlier (or to pull all common config stuff out of a group). 

> > Jason Greene wrote:
> > When you think about it, a server-group, and a cluster are really the same thing, the only difference is that the cluster has an additional set of services that a basic group does not.
> 
> Yes, but isn't the set of capabilities that a server has defined by its profile? We could say that defining a server as part of a cluster means that additional capabilities are added beyond what's in the profile. But then we are dividing the definition of a profile into two places. Also, exactly what capabilities should be added if a server is in a cluster is unclear.

I think this depends on the definition of a profile. To me our previous definition of profile focused much more on internal implementation details (how to build a server with ejb3 (which jars etc)). When I look at the domain model I am looking at it from a configuration standpoint. Specifying things like "jndi should be clustered on port blah blah blah". There should be a thread pool with X threads, etc 

> A very simple concept of a cluster is that it is a server-group that also exposes some predefined configuration properties that need to be kept consistent throughout the group. (A server-group would not have such properties by default, although users could add custom ones.) Things such as:
> 
> * Group name (current -g)
> * Type of intra-group communication to use by default (udp, tcp)
> * Default interface to use for intra-group communication
> * Default multicast address to use
> * other defaults less commonly changed
> 
> 
Right this is exactly what I was getting at. It also would represent what resources are available (datasources etc).

> 
> A cluster might also have some management capabilities besides what is available to a server-group, although I'm not sure what. It should be possible for example to perform a (rolling) redeployment to a server-group.
> 
> A separate discussion is how communication will occur between servers who are not members of a cluster. There needs to be a group communication mechanism that spans the entire domain.

I think the best way to address this is that everything in a domain will have two communication services that are distinct from everything used in clustering:
1. Configuration syncing
2. Deployment

These services could be implemented in a number of ways, but will likely need to be a simple/specialized protocol. It might even necessitate a node agent of some sort. However I think thats a conversation for later, the important thing is the notion that synching must be possible to non-clustered nodes.
> > This was what I meant by the cluster-service tag, a way to specify how a group would cluster a particular service (maybe not all services should be clustered). Although it was just something I through out there as an example. A better way likely exists
> 
> Currently how we cluster a particular service is defined in that service's configuration, it's not something applied externally. And the details of what needs to be configured are often disparate between different services, so I'm not sure those configs can profitably be externalized into some common configuration element.
> 
> Ah, or are you talking about "clustered-service" as a wrapper to describe how to manage the service, e.g. how to (re)deploy across cluster?

Don't read too much into it, it was just  a generalization. Substitute clustered-service with "jgroups-group" or "ha-jndi". 

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/536382#536382]

Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2107]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20100408/e71a6bdd/attachment.html