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

[James Perkins]

Something to consider with regards to migration, or possibly even the
notifications depending on the configuration, is having it as a
subsystem/extension gives the user the option to remove the subsystem
and/or extension. In some cases that might be okay, but others the resource
might be required. For example I believe the console and possibly CLI are
using the /core-management=capability-registry resource to query
information about capabilities.

On Tue, Sep 20, 2016 at 5:39 AM, 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
> https://lists.jboss.org/mailman/listinfo/wildfly-dev




-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160920/16d1ee7d/attachment.html