JBossDeveloper

If I understand you correctly that means the management API we expose is limited to what the users actually configure. It's no longer a fixed API.

Brian Stansberry wrote:

 

If I understand you correctly that means the management API we expose is limited to what the users actually configure. It's no longer a fixed API.

Is that not true?  The management API can do two things:

1. Perform operations which update the domain model and possibly the running state of one or more Server, and
2. Read values that reflect the currently running state of one or more configured service (though it's not clear to me how this would work - would the DC relay request and gather the data to present?  would each machine have a monitoring interface for this purpose? etc)

Am I missing something?  All I'm saying is that if nothing is configured for a domain value for a specific running service, then the server determines the default value.  If a new value is configured, it becomes part of the domain configuration and the default is no longer used.  I suppose it also implies that if a value is removed then the default takes over again and the value is no longer in the domain model.  (How we represent this would probably depend on the implementation - null or empty lists or whatever).

There's probably some other details to iron out though - for example, if a service is "autovivified" (to steal a Perl term) by another service but it doesn't appear in the domain.xml, how would the user know how to configure it?  They'd have to "define" the service (with the same name) and then configure it how they want.

There's a product requirement:

Instances will still be configurable even if they are not currently running. Changes
will become active when the instance is next started.

To me the spirit of that is its not required to have running services to properly configure things. And to me part of properly configuring things is seeing what the current values are, so I can decide whether those values are appropriate. That includes values that are defaulted. If I have to have a running JBossWeb to know that when I start a server it's going to listen for HTTP requests on port 8080, we're doing something wrong.

My phrasing about not having a fixed API was poorly worded. What I meant was, if for example a configuration API had a getHttpPort() method but whether it would return a meaningful result depends on whether they have services running, that's not really a configuration API. It's a monitoring API. A monitoring API is a reasonable part of the domain management API, but it's a distinct thing from a configuration API.

We were chatting a bit about the problem of multiple versions of AS running in the same domain, which bears on this whole area. I was interrupted and had to bail; let me get my brain back into the train of thought...

Brian Stansberry wrote:

 

There's a product requirement:

[..]

To me the spirit of that is its not required to have running services to properly configure things. And to me part of properly configuring things is seeing what the current values are, so I can decide whether those values are appropriate. That includes values that are defaulted. If I have to have a running JBossWeb to know that when I start a server it's going to listen for HTTP requests on port 8080, we're doing something wrong.

OK I've been thinking in terms of "configuration is a write operation, monitoring is a read operation", but that is, I guess, too limited of a view.

Let's continue the discussion of defaults in Alexey's new thread: http://community.jboss.org/message/546290#546290

Alexey Loubyansky wrote:

 

Scott Stark wrote:

I still think the best comprimise would be to have profile definitions in the domain in terms of the required capabilities potentially simplified by having implied capabilities associated with each application type that could be overriden by the admin.

 

Ok, this makes sense. Taking it further... The profiles in the domain schema (as they are now) are kind of redefined, i.e. it's not the same profile definition/configuration as the actual profile configuration like here http://community.jboss.org/wiki/AS6ServerSideConfiguration

Definitely.

Alexey Loubyansky wrote:

 

So, I want to clarify the purpose and meaning of this redefinition in the domain config. Perhaps, it also makes sense to choose a different name not to confuse with the actual profiles.
I think if we can make domain.xml contain only the concepts/notions that are defined in its schema, it would be the best. I.e. if it contained (was expressed in) only the terms defined for it and learning additional concepts/notions for the user wouldn't be a requirement to understand the configuration.

 

Can we think about the profiles here as a set of capabilities that might be activated once there is an application requiring them? I.e. not to think about them as defining capabailities that must be activated after the start-up?
Perhaps, something like "environment" would describe it?

Yeah, that's exactly what I was getting at.  Though like I said, Scott indicated that we still need the ability to let administrators restrict the set of subsystems that are allowed to be active for a given server group.  But this is definitely not the same as specifying the subsystems that will be started up, so yes, I agree.  Though using "environment" might be too general a term?

Alexey Loubyansky wrote:

So, what I think we can do:
- define a set of implied capabilities associated with each application type (or define the "environment" for each application type);
- if an application is mentioned in the domain.xml w/o specified by the admin "environment" it requires, we assume our defaults;
- if the admin wants to be precise, it could look like
  <application name="" path="">
    <environment name=""/>
    <environment-ref name=""/>
  </application>

I'd rather localize the configuration overrides to an explicit deployment declaration.  This gets back to a previous post I made where I gave this example of a possible way to explicitly declare a deployment in XML:

    <!-- An application deployment which is assigned to two server groups -->
    <!-- Note the sha1 hash, so we know which version of my-app.ear to deploy -->
    <deployment name="my-app.ear" sha1="12b4...2b42" server-groups="group1 group2">
        <!--
          ~ Now inside here, we can put all the overrides which apply to a specific deployment,
          ~ using a format that is perhaps specific to each deployment type
          -->
    </deployment>

Or perhaps "deployment-unit" is a better name.

I see what you're getting at with "environments" - to add a level of indirection between deployment types and their capabilities - but I'm not sure that deployment type is the right association to make.  Wouldn't it make more sense to declare the capability restrictions on either a domain-wide or per-server-group basis?  It seems to me that forbidding the use of certain subsystems at a deployment level would be considerably more complex, and I'm not sure that there's a requirement driving that idea.

For example something like this mockup:

    <!-- Domain-wide whitelist -->
    <subsystems>
        <allow name="ejb"/>
        <allow name="http"/>
        <allow name="ws"/>
        <!-- Everything else is denied -->
    </subsystems>

    <!-- The back-end servers do not have HTTP, so blacklist them -->
    <subsystems server-groups="group1">
        <deny name="http"/>
    </subsystems>

Then any deployment going to the server group which implies a requirement on a subsystem which is forbidden would receive a deployment error.  (Assuming I understand the use case correctly, that is.)

One thing is certain though: we need to identify the subsystems in question so we know what set of capabilities we're talking about in the first place.

To reply to an earlier message...

Brian Stansberry wrote:

But b) is more problematic. We could say the DC has access to all domain resources and can therefore start the components needed by any ServerGroup configuration and thereby determine the defaults. But... yuck. IMHO we should try really hard to avoid imposing any such requirement on the DC.

 

We could say the DC has the ability to query the Servers to determine defaults, but besides being a can of worms it means the admin can't just start the DC and manipulate the domain configuration.

Jason had a good solution to this problem.  The configuration classes would know the defaults (which are in their corresponding XML schemas); by having the configuration classes separate from their projects (not unlike how the metadata project is intended to work, if I understand correctly), we can have the best of both worlds.  The domain controller (DC) can map the XML configuration into these classes at the domain level, and pass the object model on to the servers, which can then use that information directly to configure and/or override the deployed services.

Basically a configuration module for a given subsystem could have these responsibilities:

1. Register any XML namespace(s) it is associated with (on the DC)
2. Have the ability to validate & convert any relevant XML segments to the corresponding object model (on the DC)
3. Be responsible for configuring the subsystem they are associated with (on the server instance) via that subsystem's individual API
4. Knowing the management operations (queries and updates) available for a subsystem, and:
   1. Making the DC aware of them, and
   2. Knowing how they affect the object model, so that
   3. when the operation is sent to the DC and is passed on to the server instances, the DC and the server instances can all update their local domain models appropriately, to retain a consistent view.
   4. Having an object representation of each management operation to effect the above.
5. Have the ability to convert the configuration they represent back into XML (on the DC)
6. Be aware of default values for any given configuration item (reflected in the schema as well)

This also would imply that the domain model passed to the server instances is actually a serialized representation.

An interesting issue this raises is how to deal with management operation failures in a server group.  In my view, the only sane way to handle it is to persist the change anyway, but make sure the admin client is aware of the problem.  This solution also enables consistent behavior between (a) making a change which affects a server which is not currently running and (b) making a change which fails to take effect for some reason.

Note that performing santiy checks and validation on the DC can minimize this (to give a simple example, the DC should be able to detect if you've assigned two services to the same port and are attempting to put those services in the same server group).

Here's a few more thoughts that fall out of this:

1. Management operations can be categorized by their type:
   1. Query operations which read a value
   2. Update operations which change or add a value
2. Management operations can be organized into two scopes:
   1. Domain scope, which affect the domain object/XML model as a whole and (in the case of updates) are validated and then propagated to the relevant servers
      1. Only values which are configured at the domain level would be visible from the domain level; deployment specific values which were not present at the domain level would only be readable at the server scope
      2. Although it is conceivable that we may decide that the DC must introspect all deployments and build a complete object model, this might or might not be practical implementation-wise
         1. But on the other hand, if we do this (effectively putting the functionality that is currently residing in the structure deployers into the DC), server startup would be lightning-fast because all the deployment information will be parsed out and validated already (and the servers wouldn't need to have those classes)...
   2. Server scope, which must not affect the domain model in any way, and which take effect only on the server for which they are targeted, keeping in mind:
      1. Some operations might be applicable to a server group, for convenience (like retrying a deployment that failed across many servers in a group with the same failure cause, which an admin can perform when the underlying problem is fixed)
         1. Though this is realized as simply a broadcast of an operation across multiple servers, accumulating whatever responses come back
      2. Extra-domain monitoring operations might fall into this category
      3. All "actual" values that pertain to deployments would be readable at this level
      4. All operations which pertain to transient run-time state (such as the failed deployment restart action I alluded to above, or other runtime administrative ops like killing connections or interrupting threads) would fall into this category

Jason points out that having the DC parse out all deployments does have a lot of advantages, and I'm starting to agree with him.

Hmm, the thing i'm not really sure is the hash in the deployment. This does not seem to be something you want to edit manually in the xml, rather something used internally. Obviously the problem is identifying the deployments with the same name in multiple deployment directories. Where we basically need to have named deployment directories, since the actual deployment URL can be different on multiple nodes.

Alexey Loubyansky wrote:

 

As I understand, subsystems (ejb, war, ws, etc) should be able to be enabled only on the highest level, i.e. the domain. On lower levels (server-group, cluster, etc) they can only be disabled.

 

I agree with David's domain-level subsystem list. To disable subsystems, I would propose to move this info to server-group element. It would give a better picture of the server-group if this information was included, IMO, than searching for another construct in the XML content (although if we encourage users to use tools to modify and view domain.xml, it might not be that important).

The question this begs is: do we require that every available subsystem be declared at the domain level?  I think we should support a default (complete) set of subsystems which are made available if none are specified, but on the other hand this is purely from the perspective of a user writing a domain.xml (possibly from scratch) which I honestly don't ever see happening (we should be providing a tool which writes out an initial domain.xml as part of initializing the domain).

Alexey Loubyansky wrote:

 

Exactly, given the complexity of the file, writting it by hand from scratch is not for grand public. Which means we must produce tools.

And if there are people who enjoy writting complex xml by hand from scratch then adding a list of susbsystems will only make it better.

I admit there are some advantages to listing subsystems.  The domain parser could do some degree of eager loading & installation of their domain-level parsing components which will simplify implementation a little.

Also it could potentially make domain-level pluggability much easier.  A mock example:

    <subsystems>
        <!-- these are built in -->
        <subsystem name="web"/>
        <subsystem name="ejb"/>
        <!-- this is provided by a third party -->
        <subsystem name="some-third-party-component" class="org.thirdparty.Thing"/>
        <!-- ... -->
    </subsystem>

Alexey Loubyansky wrote:

 

David Lloyd wrote:

Also it could potentially make domain-level pluggability much easier.  A mock example:

 

    <subsystems>
        <!-- these are built in -->
        <subsystem name="web"/>
        <subsystem name="ejb"/>
        <!-- this is provided by a third party -->
        <subsystem name="some-third-party-component" class="org.thirdparty.Thing"/>
        <!-- ... -->
    </subsystem>

 

I agree about the thirdparty subsystem idea in general. But I thought we might need a more sophisticated way to define it than just a class attribute. Actually, perhaps the same sophisticated way we will have to use to define our own subsystems. And that might actually be the profiles?

Yeah, it's just a mockup.  In reality we will use a module identifier of some sort which is used to locate the extension.  But that's a different discussion that we should revisit later.