[wildfly-dev] Migration management operation - open questions

Brian Stansberry brian.stansberry at redhat.com
Tue Aug 11 11:11:43 EDT 2015


On 8/11/15 2:59 AM, Ladislav Thon wrote:
> Inline.
>
>>> This is mostly about clarifying what should I do before starting the new
>>> server in --admin-only.
>>>
>>> In standalone -- am I supposed to copy snippets from old standalone.xml
>>> to new standalone.xml?
>>>
>>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow
>>> connected to the ability of newer domain controller to manage older servers?
>>>
>>
>> The intent here was not to let people start with a new standard config
>> shipped by us and then use these ops to import stuff from a previous
>> config. The expectation is they are starting with their existing config
>> and changing it.
>
> So this is in some ways the most important part of this discussion :-)
>
> I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10
> Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension
> 'org.jboss.as.threads' is not supported on servers running this version."
>
> Removed the extension, started again, failed with "Unexpected element
> '{urn:jboss:domain:threads:1.1}subsystem'" (of course!).
>
> Removed the "threads" subsystem, started again, failed with two error
> messages related to the "datasources" and "ejb3" subsystems.
>
> Is this the intended workflow? I didn't get further, because I somehow
> get a feeling that patching the new default configuration with relevant
> bits from the old one will be easier when only a handful of changes in
> the configuration were made, and probably on-par when the configuration
> changes were more involved. Of course it's just a feeling, but the first
> impression is important too :-)
>

Yes, that's the intended workflow, in terms of migration tooling the 
WildFly will provide.

I think it makes sense to look into how we can ease pain as much as 
possible though. Things that fail, we should see if they can be made to 
not fail.

For example, an empty threads subsystem is meaningless, so if the tread 
subsystem parser is running in a server and it sees the element is empty 
it could just basically become a no-op and not install the subsystem 
instead of registering an pointless subsystem that will just fail.


>> It's possible they'll want to start with some sort of a hybrid, i.e.
>> take our new standard config, then bring their own stuff in, and then
>> let us migrate parts. If so the user is responsible for creating that
>> initial hybrid. If some other tooling helps them with that, all the
>> better, but that's out of scope for these ops.
>
> Of course, no question about that.
>
> LT
> _______________________________________________
> 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