[wildfly-dev] Migration management operation - open questions

[Brian Stansberry]

Thanks for raising these questions here.

On 8/7/15 1:26 AM, Miroslav Novak wrote:
> Hi,
>
> we have a few questions related to correct behavior of the :migrate operation for following subsystems:
> - JBoss Web to Undertow [1]
> - HornetQ to Apache ActiveMQ Artemis [2]
> - jacorb to iiop-openjdk [3]
>
> Part of it was already clarified on wildfly-dev list [4] but there are still unspecified topics related to work flow and expected results of migration operation. We summarized them into following questions:
>
> 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.

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

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.

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

> 4. What should happen if some other subsystem is expecting definition of element in new migrated configuration but it's not there after migration?
> -- For example ejb subsystem has by default "activemq-ra" as default resource adapter for MDBs and migrated Artemis subsystem will not contain it.
>

Just to clarify, the default is hornetq-ra.

Jeff Mesnil should reply to this. I believe this may be a situation 
where we change the default value of a management attribute and then use 
a transformer to ensure slaves running previous versions still see 
hornetq-ra if the attribute value is not explicitly set.

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

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.

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

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


> Thank you,
> Mirek
>
> [1] https://issues.jboss.org/browse/EAP7-326
> [2] https://issues.jboss.org/browse/EAP7-327
> [3] https://issues.jboss.org/browse/EAP7-328
> [4] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003841.html
> _______________________________________________
> 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