Re: [wildfly-dev] Migration management operation - open questions
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat