Goal

Use a proper subsystem to manage configuration changes instead of the current 'kernel' space. This should be an update over what is described at Design notes for Configuration changes in domain mode

Legacy

How Configuration changes works in current WildFly 10 in domain mode :

* you can add /core-service=management/service=configuration-changes but it never get sent out to the slaves

* you can add the configuration-changes service on /host=*/core-service=management/service=configuration-changes which is properly stored in host.xml . Note that the CLI completion doesn't work properly.

* this is not propagated to managed servers nor to server-groups after a reload or restart, or if the managed server is started after the add

* thus /core-service=management/service=configuration-changes:list-changes() will fail after a reload or restart

* only /host=*/core-service=management/service=configuration-changes:list-changes() seems to work

Requirements

Managing configuration changes should be done in a proper subsystem that is host enabled. Thus we could take advantage of server-groups and host configuration to select the HostControllers and managed servers where this feature is enabled.

Enabling the tracking can be done through adding a configuration-changes service to the core-management subsystem.

Actually there are management operations at domain and host controller level, below you can see the add operation to enable the configuration changes and limit its history size, the following operation list the changes
Standalone

    /subsystem=core-management/service=configuration-changes:add(max-history=100)

    /subsystem=core-management/service=configuration-changes:list-changes()

Domain

    /host=<host-name>/subsystem=core-management/service=configuration-changes:add(max-history=100) 

    /host=<host-name>/subsystem=core-management/service=configuration-changes:list-changes()

  /profile=<profile-name>/subsystem=core-management/service=configuration-changes:add(max-history=100)

The HostController result should be the same as in executing the operation directly on the HostController.
  /host=<host-name>/server=<server-name>/subsystem=core-management/service=configuration-changes:list-changes()

Since we don't want this to interfere  with what was done in the first step of fixing this bug we will introduce a Capability in both the kernel and the core-management subsystem so that we can't have both running on the same server instance.

That means that if we have added /subsystem=core-management/service=configuration-changes then adding /core-service=management/service=configuration-changes will fail. The reverse is true also.

In domain mode this might have an impact if one is installed on a host and some of the managed servers use a profile with the subsystem activated.

Issue Metadata

EAP ISSUE: https://issues.jboss.org/browse/EAP7-575

RELATED ISSUES: [WFCORE-1642] Fix domain mode for configuration changes - JBoss Issue Tracker [WFCORE-1922] Use a subsystem to manage configuration changes in the future - JBoss Issue Tracker