[wildfly-dev] Proposal to add a new management subsystem to wildfly-core

[Bob McWhirter]

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 at 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 at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160921/f99e7de2/attachment.html