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

[David M. Lloyd]

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.

-- 
- DML