[wildfly-dev] Easing migration beyond the migration ops

[Brian Stansberry]

I've changed the title of this branch of the thread to better reflect 
this part of the topic. Plus to make it stand out more. :)

More below.

On 8/11/15 10:11 AM, Brian Stansberry wrote:
> 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.
>>>>

I think it makes sense to make a requirement that the user should not 
have to do anything before starting in --admin-only.

IOW, any logic we have that rejects something on a server should not do 
so in --admin-only. Instead it should log a WARN advising what the user 
should do to correct the config. For example, "To correct this, remove 
the cmp subsystem." The user can then do that if they wish.

In normal running mode if the config specifies things we cannot support 
then failing is appropriate. (There may be odd cases where for obscure 
stuff we decide to warn and not fail, but generally we'd fail.)

>>>> 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.
>

This would be a specific behavior beyond the general behavior that I 
talk about early in this post. It could happen regardless of --admin-only.

There are other "legacy only" subsystems (cmp and jaxr) that also allow 
an "empty" config. But I don't think this behavior is appropriate for 
those. Those subsystems differ from "threads" in that even an empty 
config affects server (i.e. deployment processing) behavior.

>
>>> 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