Representing Swarm, +1 because subsystems are more consistent for us.
Management core service has been an odd duck for us. We made it work but
it's weird compared to the rest.
Bob
On Tuesday, September 20, 2016, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
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/EnablingWildFlyElytronForManag
ementSecurity
[4]
https://issues.jboss.org/browse/WFCORE-1642
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <javascript:;>
https://lists.jboss.org/mailman/listinfo/wildfly-dev