Proposal to add a new management subsystem to wildfly-core

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to add a new management subsystem to wildfly-core

Jeff Mesnil
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/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

Tomaž Cerar-2
How will this behave in domain mode?

Will it be host subsystem and as such available on hosts or also on domain profiles?

On Tue, Sep 20, 2016 at 2:39 PM, Jeff Mesnil <[hidden email]> 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/EnablingWildFlyElytronForManagementSecurity
[4] https://issues.jboss.org/browse/WFCORE-1642



--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

Darran Lofthouse
In reply to this post by Jeff Mesnil
Sounds like it could be a nice home for the administrator encouragement
feature I want to look at again once I get a chance.


On 20/09/16 13:39, Jeff Mesnil 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/EnablingWildFlyElytronForManagementSecurity
> [4] https://issues.jboss.org/browse/WFCORE-1642
>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

Jeff Mesnil
In reply to this post by Tomaž Cerar-2

> On 20 Sep 2016, at 15:00, Tomaž Cerar <[hidden email]> wrote:
>
> How will this behave in domain mode?
>
> Will it be host subsystem and as such available on hosts or also on domain profiles?

It will be available as a host subsystem and on domain profiles.
There might be resources that makes sense only for HC or for servers but that’s not different from some existing resources under /core-service=management.

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

kkhan
In reply to this post by Jeff Mesnil
Thinking down the line, if we
-do migrate everything from /core-service=management, and/or:
-add a lot more future 'core' functionality to subsystems

I don't think we want one monolithic subsystem replacing this/doing everything. For now that doesn't sound too important, but should be taken into consideration when deciding on the name of the current subsystem.

> On 20 Sep 2016, at 13:39, Jeff Mesnil <[hidden email]> 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/EnablingWildFlyElytronForManagementSecurity
> [4] https://issues.jboss.org/browse/WFCORE-1642
>
>
>
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

Brian Stansberry
In reply to this post by Jeff Mesnil

> On Sep 20, 2016, at 8:22 AM, Jeff Mesnil <[hidden email]> wrote:
>
>
>> On 20 Sep 2016, at 15:00, Tomaž Cerar <[hidden email]> wrote:
>>
>> How will this behave in domain mode?
>>
>> Will it be host subsystem and as such available on hosts or also on domain profiles?
>
> It will be available as a host subsystem and on domain profiles.
> There might be resources that makes sense only for HC or for servers but that’s not different from some existing resources under /core-service=management.
>

This is an important general topic for the roadmap discussion.

Right now a domain mode server gets some of its config from its server-group/profile in the domain.xml part of the config, and then some from the host’s own config. And a lot of what comes from the host is currently encapsulated in the core-service=management resources.

Right now host controller subsystems don’t allow the option of being applied to the servers; they are only used by the HC process. If we ever want the HC subsystem settings to apply to the servers as well, we’d need to add that (w/o breaking compatibility).

For the specific use case you’re working, Jeff, I think the way HC subsystems work right now is fine. Add the subsystem to the domain profile if you want it on the servers; add it to the HC if you want it on the HC. It’s quite realistic people would only want one or the other.

As we think about what other things we might migrate to a subsystem=core-management we need to think whether those items will follow that same pattern. If we identify some that won’t, then we need to decide what to do. Ideally there won’t be any such cases.

Here’s what’s presently part of a server’s <management> configuration:

1) configuration-changes — this is one we should consider moving to the subsystem in WF 11
2) security-realms — now comes from host.xml, but is being replaced by elytron, which presumably is now configured in domain.xml
3) outbound-connections — now comes from host.xml
4) audit-log — now comes from host.xml, via a kind of funky config style on the host. Would coming from domain.xml be better?
5) management-interfaces — now comes from host.xml, and probably can still be set up by the HC. Given the current meaning of these resources, this is not really something particularly user configurable; the HC sets up the connections it wants so *it* can talk to the server; end user connectivity to the server is via the HC. If we start adding more things to these resources (e.g. there’s a discussio of adding other contexts) then it gets more complicated.
6) access-control — this comes from the domain and is a domain-wide configuration not overridable at any lower level. As such, it’s not a good candidate for subsystem=core-management.

> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

James Perkins
In reply to this post by Jeff Mesnil
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 <[hidden email]> 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/EnablingWildFlyElytronForManagementSecurity
[4] https://issues.jboss.org/browse/WFCORE-1642



--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

Brian Stansberry
Right; we would not move things like that to a subsystem. The core-service=management/service=management-operations resource tree is another one.

These things are present in the kernel whether the user configures anything or not.

> On Sep 20, 2016, at 4:28 PM, James Perkins <[hidden email]> wrote:
>
> 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 <[hidden email]> 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/EnablingWildFlyElytronForManagementSecurity
> [4] https://issues.jboss.org/browse/WFCORE-1642
>
>
>
> --
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

Bob McWhirter
In reply to this post by Jeff Mesnil
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 <[hidden email]> 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/EnablingWildFlyElytronForManagementSecurity
[4] https://issues.jboss.org/browse/WFCORE-1642



--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;wildfly-dev@lists.jboss.org&#39;)">wildfly-dev@...
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to add a new management subsystem to wildfly-core

Jeff Mesnil
In reply to this post by kkhan

> On 20 Sep 2016, at 17:12, Kabir Khan <[hidden email]> wrote:
>
> Thinking down the line, if we
> -do migrate everything from /core-service=management, and/or:
> -add a lot more future 'core' functionality to subsystems
>
> I don't think we want one monolithic subsystem replacing this/doing everything. For now that doesn't sound too important, but should be taken into consideration when deciding on the name of the current subsystem.

That’s a good point.
My idea was that this core-management subsystem would contain resources targeted for both servers and host controllers.
If/when we want to add features that are meant for host controllers only, it’ll be possible to add a 2nd subsystem (e.g. named host-management) that’d be provided by the same extension.

jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev