[wildfly-dev] Migration management operation - open questions

Mon Aug 10 12:33:13 EDT 2015

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.

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.

If we don't warn but fail it certainly makes sense for these handlers to 
defer failing as long as possible and gather up all problems into one 
failure message.

>
>> That said, we need to be careful about having the scope of the handlers
>> grow too large, forcing handlers for one subsystem to be tightly coupled
>> to the implementation details of other subsystems or the kernel. Your
>> questions 2-4 relate to this kind of scope question. If the coupling
>> between different parts of the system starts to get too deep, IMO it
>> starts to move beyond the intended scope of these operations and into
>> the realm of higher level tools like Red Hat's Windup tool. It's a
>> judgement call but my feeling is what the handlers are currently doing
>> (e.g. the stuff I mention in my answer to #2) is reasonable.
>
> and my opinion here is that the :migrate operation should detect any
> possible problems that stem from the configuration of the old subsystem
> (e.g. an attribute in the old subsystem allowed values A|B|C, but the
> new subsystem only allows A|B). Problems caused elsewhere (socket
> bindings, other subsystems, ...) can be deferred to server startup.
>
> The key here is to agree on this :-)
>

I agree with that.

>>> 6. Should the extensions for old subsystems be left in configuration after migration?
>>>
>>
>> In a domain, yes. The migration of a subsystem in one profile does not
>> mean the extension is unavailable for use in another profile.
>>
>> I don't have a strong opinion about this in standalone.
>>
>> I do suspect there may be a technical barrier to removing the extension
>> though. If so I doubt we'll do it in WildFly 10.
>
> I think we're fine with leaving them there, this was just to clarify.
>
>>> 7. Should the :migrate operation return reload-required header?
>>>
>>
>> The migrate operations function by executing operations to add and
>> remove resources. If those operations themselves put the process in
>> reload-required, then the header will be returned. If not, it won't.
>>
>> The migrate operations all require that the process be running in
>> --admin-only mode. So I would not expect the outcome to be a need to put
>> the process in reload-required. Most likely that outcome would be a bug.
>> We use reload-required when changes to the persistent configuration
>> cannot be reflected in existing running services, but in --admin-only
>> there are no running services associated with these subsystems.
>
> Makes sense, thanks.
>
> 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