9:39 p.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/
10 p.m.
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 <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
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:22 p.m.
On 20 Sep 2016, at 15:00, Tomaž Cerar <tomaz.cerar(a)gmail.com>
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/
1:10 a.m.
On Sep 20, 2016, at 8:22 AM, Jeff Mesnil <jmesnil(a)redhat.com>
wrote:
> On 20 Sep 2016, at 15:00, Tomaž Cerar <tomaz.cerar(a)gmail.com> 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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
10:06 p.m.
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
12:12 a.m.
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 <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/EnablingWildFlyElytronForManagementSecurity
[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
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:52 p.m.
On 20 Sep 2016, at 17:12, Kabir Khan <kabir.khan(a)jboss.com>
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/
6:28 a.m.
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(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
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
6:52 a.m.
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
<jperkins(a)redhat.com> 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 <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/EnablingWildFlyElytronForManagementSecurity
[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
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
1:03 p.m.
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
2784
days inactive
2787
days old
9 comments
7 participants
participants (7)
-
Bob McWhirter -
Brian Stansberry -
Darran Lofthouse -
James Perkins -
Jeff Mesnil -
Kabir Khan -
Tomaž Cerar