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