[jboss-jira] [JBoss JIRA] (AS7-3174) Ability to configure a Host Controller to ignore domain model changes

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/AS7-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663124#comment-12663124 ] 

Brian Stansberry commented on AS7-3174:
---------------------------------------

The fundamental intent of this feature is to support large domains with a variety of server groups running different configs. The servers in each server-group should be consistent. Generally, all servers in a given group would be running the same AS version (at least after a rolling upgrade process is done.) But, if host A isn't running servers in server-group X, it shouldn't be forced to understand new configuration items only relevant to server-group X. As long as it can understand the configuration pieces relevant to its servers, it's fine. 

Lower level stuff would basically mean contents of profiles, socket-binding-groups or server-groups. 

For profiles, the whole notion of a profile is it is meant to be consistent in all servers in the group. Allowing servers on some hosts to ignore parts of the profile seems like opening up a huge can of worms.

Similar logic applies to socket-binding-groups. Plus, we already support overriding the socket-binding-group within a host.xml <server> element. So if for some reason a host can't support some feature in socket-binding-group X but the servers on that host don't really need that feature, a socket-binding-group Y can be created that doesn't have those features and the servers on the old-version host can be configured to use it. (Admittedly, this scenario is a stretch.)

For server-groups, again, all members are meant to be consistent. Allowing pieces of config to be ignored on some servers in the group is opening up a huge can of worms.
                
> Ability to configure a Host Controller to ignore domain model changes
> ---------------------------------------------------------------------
>
>                 Key: AS7-3174
>                 URL: https://issues.jboss.org/browse/AS7-3174
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 7.1.0.Final
>
>
> To ensure that, for example, and EAP 6.0 slave HC can run inside domain managed by an EAP 6.1 master HC, we need a mechanism to allow the slave HC to safely "ignore" commands from the master. This will allow, for example, new-in-EAP6.1 extensions and subsystems to be added to the domain config. The servers managed by the 6.0 HC could not be part of server-groups that use those new extensions/subystems, but other servers managed by other HC's could.
> My thought on this is to add a child element to <domain-controller>, paired with <remote> (i.e. it would not be available if <local/> is used.) Something like:
> <excludes>
>    <profiles>
>      <profile name="newstuff"/>
>      <profile name="addedstuff"/>
>    </profiles>
> </excludes>
> The <profiles> wrapper may not be necessary.
> Beside profile the following could be excluded:
> extension
> system-property
> path
> interface
> socket-binding-group
> server-group
> deployment
> rollout-plan
> If the user tried to add a server that used one of the excluded server-groups, it would fail with an appropriate error message.  If the new server's server-group used one of the excluded profile, socket-binding-group or deployment elements it would fail, it would fail with an appropriate error message. If a non-excluded profile used an excluded extension, that would fail due to the absence of the extension. (For bonus points, in a later release would could detect why the extension was missing and give a better error message.) If some non-excluded resource relied on an excluded system property, interface or path, that would fail at runtime, as there's no reliable why to detect that situation. However, path, interface and system-property are really on the above list just to be thorough; I don't anticipate a reason why a later release would include elements in those configs that an earlier release could not handle.
> When we add back in the <include> element to profile and socket-binding-group we'll need to account for this as well (i.e. a non-excluded child can't include an excluded parent.)
> Note also that the basic rule is operation handlers should ignore parameters they do not understand, rather than failing. So the addition of some new attribute in 6.1 should not cause the add handler for a resource on a 7.1 HC/server to fail. An entirely new resource address would trigger failure though; hence the new for this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira