[wildfly-dev] can we get host controllers to push out subsystem extension modules?
Brian Stansberry
brian.stansberry at redhat.com
Mon May 2 14:39:09 EDT 2016
On 5/2/16 1:13 PM, Brian Stansberry wrote:
> No, the only content types we propagate are deployments and rollout
> plans; the stuff that goes in the content repo. Way back at the
> beginning of AS 7, we decided provisioning was out of scope for the
> server and was a JON function. We've considered expanding beyond that
> from time to time, but have never had time. Considered it primarily
> people requesting that modules get pushed around the domain,
> particularly datasource drivers. This is basically a request for module
> propagation.
>
> It is a slightly easier variant of that request though. A key
> requirement with a general module propagation thing is we have to track
> what's available so newly joining hosts can request any necessary
> missing content. That basically means referring to those modules in the
> domain.xml config. With extensions though we already have that reference
> in place.
>
BTW, I was brainstorming a bit in that last paragraph, forgetting that
I'm talking to someone who works on something that is a proper
layer/add-on on top of WildFly, not an end user writing their own
extensions. Proper layers/add-ons need to patchable, which adds another
whole set of requirements beyond just needing to get bits replicated.
> On 5/2/16 12:58 PM, John Mazzitelli wrote:
>> <TL;DR>
>> If I define my own subsystem configuration in one of the domain controller's profiles, can the DC/HC push out my subsystem extension module to the managed standalone servers just like it pushes out deployments to them?
>> </TL;DR>
>>
>>
>> In WildFly's Domain Operating Mode you can define Server Groups in your Domain Controller configuration [1]. In these Server Groups you say what deployments should be deployed on which servers, like this:
>>
>> <server-group name="main" profile="default">
>> <deployments>
>> <deployment name="foo.war" runtime-name="foo.war" />
>> </deployments>
>> </server-group>
>>
>> The DC and HC will do their thing to ensure those deployments are installed on the managed standalone servers. [3]
>>
>> Additionally in your Domain Controller configuration, you can define profiles with different subsystems [2] (so presumably some managed standalone servers can have some subsystems, where others in different profiles don't have to have them - or at least could be configured differently). For example:
>>
>> <profiles>
>> <profile name="default">
>> <subsystem xmlns="urn:jboss:domain:web:1.0">
>> <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>
>> [...]
>> </subsystem>
>> <subsystem xmlns="urn:jboss:domain:fictional-example:1.0">
>> <socket-to-use name="unique-to-bigger"/>
>> </subsystem>
>> [...]
>> </profile>
>> </profiles>
>>
>> My question is - does the DC and HC manage that "fictional-example" subsystem extension module just like they handle deployments? In other words, will that subsystem's module get pushed out to the managed standalone servers (in the same way the DC/HC ensures the deployments are pushed out to the managed standalone servers?) If so, where do you put the module directory? On the DC, like deployments [3]? If not, how does this "fictional-example" subsystem that is defined in the profile make its way to the managed standalone server?
>>
>> Thanks,
>> John Mazz
>>
>> [1] https://docs.jboss.org/author/display/WFLY10/Operating+modes
>> [2] https://docs.jboss.org/author/display/WFLY10/Domain+Setup
>> [3] https://docs.jboss.org/author/display/WFLY8/Application+deployment
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list