[wildfly-dev] Migration management operation - open questions

[Brian Stansberry]

On 8/10/15 3:23 PM, Jason Greene wrote:
>
>> On Aug 10, 2015, at 11:33 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 8/10/15 10:59 AM, Ladislav Thon wrote:
>>> Brian, thanks for answering. I'll clarify some qustions below (and I
>>> hope that others from our team will join too).
>>>
>>>>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode?
>>>>>
>>>>
>>>> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this
>>>> part. Ideally this would be covered somewhere in
>>>> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent
>>>> is all three of these have common semantics.
>>>>
>>>> The biggest thing is these ops all require that the target process is
>>>> running in --admin-only mode.
>>>
>>> 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.
>>
>> 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.
>>
>>>>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning?
>>>>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding?
>>>>>
>>>>
>>>> The migrate operation is used to migrate a valid configuration. What you
>>>> describe is an invalid configuration, as the needed socket-binding is
>>>> not present.
>>>
>>> So if the migration approach is to "copy all required snippets from old
>>> configuration to the new one", I have to copy all dependencies (e.g.
>>> socket bindings) too. Makes sense, though maybe we had a different
>>> situation in mind here that I can't recollect now... :-(
>>>
>>>> The migration operation should not remove external configuration (e.g.
>>>> remove a socket-binding), as the ability to determine what other uses
>>>> there may be in the overall config for that config is beyond the scope
>>>> of the migration op handler.
>>>
>>> Sure.
>>>
>>>>> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
>>>>> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>>>>>
>>>>
>>>> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
>>>> handler for the web subsystem migrate op) it looks to be adding a
>>>> security realm.
>>>
>>> This is probably the right thing to do, but we wanted to be sure. We've
>>> seen some possible problems with this (e.g. name collisions), so we
>>> thought that it's better to ask :-)
>>>
>>
>> It's a good question. They all are. :)
>>
>> What WebMigrateOperation does is create a synthetic realm name by
>> starting with a base name and adding a digit, looping and incrementing
>> the digit until it finds a name that doesn't collide.
>>
>>>>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime  the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this?
>>>>>
>>>>
>>>> I think the op should fail (not just warn) if the subsystem cannot be
>>>> properly migrated.
>>>
>>> I can agree both with this and with the other approach of "it's probably
>>> easier for the user to fixup the new subsystem then it is to repeatedly
>>> alter the old subsystem until you get something that will convert" [1].
>>>
>>> [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html
>>>
>>> The idea here is that if the :migrate operation can see a possible
>>> problem, then the problem must be reported during :migrate and not only
>>> when the migrated server is started for the first time. Of course I
>>> agree with
>>
>> Good point. I'll let Jason and the guys who actually wrote these respond
>> further.
>
> I was simply voicing an opinion at the time. I think the conversation ended at that point, and I didn’t feel strongly enough about it raise it again.
>

Ok. Well, it's in the Beta implemented as "fail if there is a problem." 
If anyone wants to change that, it's pretty much speak now or never.

>>
>> The idea of warning is problematic. Management ops return a result or a
>> failure, not a result + a warning. We can of course warn in the server
>> log, but I think it's dangerous to reply with a success result and then
>> count on the possibly-remote user to notice a server log message.
>
> Right my thinking was the result would be the migration status. The actual migration is the actions it takes. Granted, a major challenge is that all of this work happens in a composite.
>

That could work.

We also have a "describe-migration" op, for which the result is the list 
of ops to take to do the migration yourself. (It doesn't actually do the 
migration.) If we wanted some sort of "migration status" result for the 
"migrate" op we'd need to change the structure of the 
"describe-migration" result as well to additionally include that info. 
The two should be consistent about this.

When you talk about "composite" are you referring to the not multi-step 
nature of how these ops actually internally do the migration? If so
I don't think dealing with those other steps is practical. The only 
thing we could warn about would be stuff the migration handler itself 
identifies. If then there is some problem that occurs when executing the 
add/remove steps the migration handler runs, I don't think it's 
practical to do anything but fail.

>
>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat