[wildfly-dev] Redesigning http-upgrade configuration for management

[Darran Lofthouse]

+1 I now prefer the form of config where we do include the wiring 
together - but I think others don't, especially for the core management.

In the case of management it is trying to avoid depending on an endpoint 
and instead depend on an endpoint that is accessible in some way.

My suggestion was really a hybrid of the two.

On 17/09/15 12:38, David M. Lloyd wrote:
> On 09/17/2015 05:18 AM, Darran Lofthouse wrote:
>> On 16/09/15 19:11, Brian Stansberry wrote:
>>> For example, I believe http-upgrade is an implementation detail. What
>>> the resource is really about is providing JBoss Remoting-based
>>> management in an HTTP environment. We refer to that elsewhere as
>>> "native" (i.e. in
>>> /core-service=management/management-interface=native-interface) So is
>>> this resource primarily about native management?
>>
>> That sounds like where I was starting to come from regarding a new
>> design to move this into a subsystem - we actually have a bit of a
>> mixture when it comes to defining how different interfaces are exposed.
>>
>> I was considering that at the top level we have a resource that
>> represents the protocol being exposed.
>>
>> I was then considering attributes to define how it is exposed, from
>> subsequent capability related discussions those would probably have to
>> be child resources.
>>
>> In XML terms it would be something like: -
>>
>> <native-interface sasl-authentication="...">
>>        <remoting />
>>        <direct socket-binding="..." />
>>        <http-upgrade use-http-binding="..." undertow-listener="..." />
>> </native-interface>
>> <http-interface http-authentication="...">
>>        <direct http-socket-binding="..." https-socket-binding="..."/>
>>        <undertow-listener name="..." context="/management" />
>> </http-interface>
>>
>> Names chosen were just to illustrate the hierarchy but general principal
>> was the parent is what is exposed, the child is how it is exposed.
>
> Assuming that we are still planning following through with moving
> everything into subsystems/enabling HC subsystems like we discussed last
> January, and given cap/req, shouldn't we seriously consider making it
> something more closely approximating this:
>
> <subsystem xmlns="...remoting...">
>       <endpoint id="management" name="${jboss.node.name}-management">
>           <http-connector name="blah" sasl-authentication="rem-sasl"
> connector-ref="mgmt-connect" .../>
>       </endpoint>
> </subsystem>
> <subsystem xmlns="...network...">
>       <interface name="management">
>           <inet-address value="127.0.0.1"/>
>       </interface>
>       <socket-binding-group name="standard-sockets">
>           <socket-binding name="management-http" interface="management"
> port="${jboss.management.http.port:9990}"/>
>           <socket-binding name="management-https" interface="management"
> port="${jboss.management.https.port:9993}"/>
>           ...boring stuff here...
>       </socket-binding-group>
> </subsystem>
> <subsystem xmlns="...sec-elytron...">
>       <security-domain name="main-domain">
>           <sasl-authentication name="rem-sasl">
>               ...boring stuff here...
>           </sasl-authentication>
>           ...boring realm stuff here...
>       </security-domain>
> </subsystem>
> <subsystem xmlns="...undertow...">
>       <server name="mgmt-server">
>           <http-listener name="default" socket-binding="management-http"
> .../>
>           ...boring stuff here...
>       </server>
>       ...boring stuff here...
> </subsystem>
> <subsystem xmlns="...management...">
>       <remoting endpoint="management"/>     // this is an attribute, not
> a sub-resource
>       <security-domain name="main-domain"/> // this is an attribute, not
> a sub-resource
>       ...boring stuff here...
> </subsystem>
>
> That said if we're not making the move to subsystems, I guess I don't
> really care how it's all laid out too much, but using cap/req whenever
> possible will make any such future move go more smoothly, IMO.
>