[jboss-jira] [JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model

[ehsavoie Hugonnet (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFCORE-1340:
-----------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Brian Stansberry)


> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
>                 Key: WFCORE-1340
>                 URL: https://issues.jboss.org/browse/WFCORE-1340
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>             Fix For: 2.1.0.CR2
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured.
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
> Proposed structure:
> Resources are at address /host-exclude=*
> Attributes are:
> * management-major-version
> * management-minor-version
> * management-micro-version
> * host-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
> If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * excluded-extensions
> * active-server-groups
> * active-socket-binding-groups
> The excluded-extensions attribute is a list of extension names the resources that  (/extension=X) the DC should hide from the target hosts. Generally because the hosts will not have the necessary extension modules in their installation.
> The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* excluded from the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be hidden; all others of these types will be hidden. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the server groups listed in active-server-groups is not the complete set of sbgs needed on servers running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
>  
> Adding a new group to active-server-groups or active-socket-binding-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data. A reload or restart of the slave or master causes a reconnect.
> Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data. 
> There is other data that could be included in these resources, e.g. fine grained "exclude" information matching what can be configured in in the ignored-resources elements host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand. If a slave has ignored-resources explicitly configured, that information will be used in managing that slave, in combination with any matching configuration in a host-exclude. However, the related ignore-unused-configuration setting added in WildFly Core (not present in EAP 6) will be handled differently.
> A WildFly Core 2 or later slave will send its ignore-unused-configuration setting when it registers. If this is set to 'true', the DC will not use any of the domain wide active-server-groups and active-socket-binding-groups data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC as to what should server-groups, profiles and socket-binding-groups be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication. However, the domain-wide 'excluded-extensions' data *will* be used for the slave.
> An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)