8:39 a.m.
Hi,
TL;DR let's add a new subsystem to wildly-core to add new management-related resources
instead of putting them in /core-service=management. Let's do that for WFLY 11.
# Use case
For WildFly 11, I have planned a new feature[1] to be able to notify user code when the
state of the server changes (running, reload-required, etc.).
Until now this kind of resources related to the server management were put under
/core-service=management.
However, this resource does not have well-defined semantic (e.g. what's the meaning of
/core-service=management for a DC?).
Brian proposed to stop putting resources under this resource and add a new subsystem
instead. This will clarify the semantic of the resources and uniformize the configuration
and management of WildFly.
I propose to create a new extension in wildfly-core project to provide new management
resources.
It will be the *successor* of /core-service=management (i.e. we stop adding *new*
resources to /core-service=management).
This will not be a replacement for /core-service=management. Current resources under
/core-service=management will remain there for WildFly 11.
I have no strong opinion about what doing after that: we can move/migrate them under the
new subsystem, redirect them using alias or do nothing.
Some resource related to security will be deprecated by Elytron so doing nothing sounds
correct for them.
Moving everything else to the new subsystem sounds a worthy goal but I have no idea of the
actual effort to do so (and ensure that we remain compatible). The time and energy spent
on this may not be worthwhile...
# What is the scope of this subsystem?
The scope would be identical to the /core-service=management resource.
Using a subsystem just make sure we have well-defined semantics for the resources
underneath it. It also moves us towards the goal of extending WildFly in an uniform way
instead of adding special resources outside of our extension API.
It is *not* a subsystem to manage WildFly or deployed applications à la JMX or JSR 77.
# What is the name of this subsystem?
The intuitive name would be /subsystem=management but I don't think it is a good name.
It is too generic (does it expose a management API à la JMX? does it provide management
features based on other project such as Hawkular?) and I don't think we should own
such general term (even though we do have such general subsystem names such as io,
security, logging).
If we follow the current convention, the name could be /subsystem=management-wildfly
(feature + name of project providing the feature) but it does not sound good. The
subsystem provides a way to manage WildFly, it does not provide a management feature
*using* WildFly (this could also clash with name of the extension if/when we implement
Java EE Management API 2.0[2]).
I prefer */subsystem=core-management* (or /subsystem=wildfly-management as a 2nd choice).
We have identified a few resources that are good candidates for this new resource:
* the feature to notify user code of server stat changes[1]
* Elytron needs a new access=identity resource[3]
# Roadmap
I propose to create asap an empty subsystem as a first step so that Elytron feature is not
blocked by the development of my own feature (It should be a single commit on wildfly-core
and can be fit in Elytron PRs if needed).
Then, we can have different PRs for new management resources that fits in this new
subsystem.
We've also identified a simple management resource to evaluate the cost of
moving/migrating/redirecting resources with the service=configuration-changes[4] and their
implications for compatibility.
Would you guys agree with that proposal?
[1] https://issues.jboss.org/browse/WFCORE-1405
[2] https://www.jcp.org/en/jsr/detail?id=373
[3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManagementSecurity
[4] https://issues.jboss.org/browse/WFCORE-1642
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/