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

[Brian Stansberry]

> On Sep 20, 2016, at 8:22 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
> 
>> On 20 Sep 2016, at 15:00, Tomaž Cerar <tomaz.cerar at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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