Domain model work in AS 6.0.0

[brian.stansberry]

We're starting to have some in depth discussions around adding the domain model (http://community.jboss.org/thread/150184?start=0&tstart=0) and Jason has added a requirements design doc (http://community.jboss.org/docs/DOC-15098). But there's also been discussion of getting some of this in AS 6.0.0.CR1, which we were hoping to get out in June. (Really hoping for a GA in June, so to hit that a CR would be early June at latest.)

My purpose in this thread is to focus on the requirements and feasibility of doing that. Somewhat isolate that discussion from the broader design discussion to prevent discussions becoming a tangled mess.

Initial list of pros and cons of getting something in AS 6.0.0:

Pros:

1. End user benefit of a centralized configuration document.
2. Community bake time for:
   1. The document schema itself
   2. Any management interfaces we provide (e.g. views in embedded JOPR)
   3. Any of the implementation details (e.g. persistence mechanisms)
3. Deadline forces us to get something done, promotes a release early release often mindset
4. Getting the core domain.xml in 6.0 allows to produce a 6.1, 6.2 etc over the following few months with added capabilities. Not including it basically means that we need to start pushing AS 7 milestones to make progress. (Assumption: this is such a big change that it requires a major release).

Cons:

1. Risk to the AS 6.0.0 timeline for something that is not part of the core goal of AS 6.0 -- EE 6 web profile.
2. Risk of poor quality of implementation given the time involved.
3. Working toward a standalone server goal for AS 6.0 leads to a suboptimal design that has to be scrapped to achieve the multi-server objective.

In my next post I'll comment a bit about requirements.

[brian.stansberry]

Jason's requirements doc is more focused on the long term goal. But what's required for an AS 6.0 to achieve the "pros" listed above?

1. At a minimum I think we need a domain.xml schema that fully covers the single server case. This should be quite close to what we would expect to use in AS 7 and EAP 6. For later releases add elements related to multi-server use cases, perhaps some wrapper elements around the 6.0 stuff, but the guts of an AS 6 domain.xml should be recognizable in an AS 7 document.

That's really the core thing that allows most of the "pros" I listed.  If we can't do that, I don't see much point.

Beyond that:

2. Persistence of changes made via admin interfaces back to the domain.xml (as opposed to just persisting them AS 5-style to the data dir and then overlaying them on top of what comes out domain.xml).

Not including 2. means an AS 6.0 domain.xml isn't really the authoritative document, it's just a centralized configuration file, helping users avoid digging through our myriad of xml. Which is a worthy goal.  But not including 2. means we're not getting much of the community bake time benefit. OTOH not including 2. may somewhat reduce the "con" risk of a suboptimal design, as a lot of the design difficulties center on the persistence aspects.

3. Embedded console management interface stuff. This is really part and parcel of 2. If 2. is out-of-scope for AS 6.0 then the existing user interfaces in the embedded console are sufficient. If 2. is included, we'd need to solve the problem of how to distinguish actions that affect the domain model from those that do not.

4. Other user interfaces (CLI, REST). I don't see why this would need to be in an AS 6.0.

Bottom line: is my 1. above a sufficient goal to make this worth doing in AS 6.0? If yes then we can discuss whether it is doable.

[starksm64]

I'm doubtful we will have a domain.xml implementation that covers the most common configuration elements we would want in a reasonably full implementation. However, I think the discussion needs to focus on the fact that until we do have a domain.xml implementation, our server is not really managable in a way we can compatibly evolve.

The first step in deciding if the 6.0 GA is possible is what the minimal schema that makes the effort worthwhile.

The reason I'm doubtful we can have a fully complete implementation is that I envision a fair amount of work to get a mapping implemented that goes from the domain metadata to the corresponding deployment metadata, along with proper handling of persistence, your issue 2. I don't believe we can have the domain.xml be anything other than a centralized configuration file in AS6.0 for sure.

3 is an issue we will have to solve even if the domain.xml is just a centralized configuration file because we still have to write back any changes made via the profileservice that intersect with the domain.xml. I'm of the opinion that until we do define a domain.xml we really do not have a manageable server. The fact that we introduced an indirection layer that allows for JON to create an rhq-plugin.xml type of mapping is still incomplete because short of JON providing the UI to view the supported "domain model", we don't know what components are managable.

4 is not important in terms of implementation version. What matters is that we have a consistent mechanism to administer servers that the AS exposes and maintains the responsibility of compabitily as it evolves. We are taking over the problem that JON has been trying to hack in, and we have been rightly criticized as a weakness.

[jason.greene]

IMO we need to at least flesh out the core domain model content/structure, including how multiple servers should be represented, so that we don't end up redoing all of this again. However, we certainly don't have to implement all of it in one stroke. We could for example define a full domain schema, but not implement the clustering portion (require that people manually copy the file around).

Once we have done this, we can start looking at timelines.

[brian.stansberry]

Scott Stark wrote:

The first step in deciding if the 6.0 GA is possible is what the minimal schema that makes the effort worthwhile.

Partly in response to this and partly because it seemed useful in general, I did a rough analysis[1] of which of the AS's existing configuration files include content that needs to be represented in a domain model. For each file (or dir in the case of exploded deployments), I assigned it to a category:

• YES -- includes relevant end-user configuration
• BORDERLINE -- some end-user configuration but not clear if they need to be managed
• QUESTIONABLE -- more doubtful than BORDERLINE
• PROBABLY NOT -- NO, but worth another look
• NO -- doesn't involve end-user configuration, e.g. purely IOC stuff

Basically a vague sliding scale as to whether we need to concern ourself with a particular file.

[1] attached for now to Jason's requirements wiki

[starksm64]

One thing we have to be clear on is that the domain.xml is going to address a small set of what is configurable via the large number of metadata files Brian has listed. The scope of the model is largely going to be based on timeboxing.

I agree with Jason that we need to have an idea of what the admin DSL model is over the long term as the model has to evolve in a compatible way in order for it to be a stable admin API.

[starksm64]

For the YES, this is my quick overview. Again my concern is having suffucient structure to be able to evolve the domain model, but a sufficiently limited scope in terms of content to be able to have an implementation.

bindingservice.beans - All of the containers/services intersected by this need associated entries in the domain model such that this configuration can be dropped.

login-config.xml,
hornetq-*.properties,
jbossws-*.properties,
jmx-console-*.properties - definitely need a domain model for security stacks and users.

properties-service.xml - Need to define how jvm, system properties are pulled in to control bootstrap and affect other configurations that reference properties.

jboss-logging.xml - I guess this is pretty much pulled into the domain?

*{container}.deployer/.xml,
deploy/hornetq/hornetq-configuration.xml,
thread-pool-j-b.xml - In general, I think we need the following common mappings for containers in the domain metadata:
- thread pools
- clustering groups
- transport stacks
- instance pools

legacy-conf-jboss-service.xml - shouldn't this just be eliminated?

hsqldb-ds.xml, any other resource factory - We need a server resources factory configuration model forthe various standard types.

mod_cluster.sar,
jboss-cache-manager.sar,
jgroups-channel-factory.sar,
deploy-hasingleton-jboss-beans.xml,
farm-deployment-j-b.xml,
hajndi-j-b.xml,
hapartition-jboss-beans.xml, - Need a cluster domain metadata model

jbossweb.sar/server.xml,
ejb3-connectors-j-b.xml,
remoting3-j-b.xml,
remoting-j-b.xml,
xnio-provider.jar - Need a connector/transport domain metadata model

jacorb.properties,
mail-service.xml,
monitoring-service.xml,
schedule-manager-service.xml,
scheduler-service.xml,
juddi-service.sar,
snmp-adaptor.sar,
uuid-key-generator.sar,
monitoring-service.xml,
*-activator-j-b.xml, - I don't see these as being in scope for an initial release

[brian.stansberry]

Scott Stark wrote:

For the YES, this is my quick overview. Again my concern is having suffucient structure to be able to evolve the domain model, but a sufficiently limited scope in terms of content to be able to have an implementation.

bindingservice.beans - All of the containers/services intersected by this need associated entries in the domain model such that this configuration can be dropped.

Yep. This will probably mean some other stuff (iiop, snmp) get pulled in, at least the socket configurations.

The SBM does provide two other nice benefits:

1. The easy-to-specify "for this server offset base port numbers by XX". Which can be a server-level property in a domain model.
2. A central view to all the port configurations. Which is just a view on the domain model; doesn't mean they all need to be configured in the same place.

mod_cluster.sar,
jboss-cache-manager.sar,
jgroups-channel-factory.sar,
deploy-hasingleton-jboss-beans.xml,
farm-deployment-j-b.xml,
hajndi-j-b.xml,
hapartition-jboss-beans.xml, - Need a cluster domain metadata model

mod_cluster is a bit of an outlier, as it doesn't require any sort of intra-cluster communication; can be applied to a server-group.

jbossweb.sar/server.xml,

ejb3-connectors-j-b.xml,
remoting3-j-b.xml,
remoting-j-b.xml,
xnio-provider.jar - Need a connector/transport domain metadata model

Leave other server.xml stuff (e.g. valves) out of scope?

[starksm64]

Brian Stansberry wrote:

Yep. This will probably mean some other stuff (iiop, snmp) get pulled in, at least the socket configurations.

The SBM does provide two other nice benefits:

1. The easy-to-specify "for this server offset base port numbers by XX". Which can be a server-level property in a domain model.
2. A central view to all the port configurations. Which is just a view on the domain model; doesn't mean they all need to be configured in the same place.

I agree that both of these are something we should support. For cross configuration views the domain metadata should have the properties annotated with the view type as an example.

Leave other server.xml stuff (e.g. valves) out of scope?

It is so common that people do configure valves, so we may have to support them in some manner.