[wildfly-dev] Migration management operation - open questions

[Jason Greene]

> On Aug 20, 2015, at 4:01 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
> 
>> On 10 Aug 2015, at 17:08, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 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.
> 
> I have a such an use case where I can’t migrate feature from the legacy messaging subsystem to the new messaging-activemq subsystem.
> 
> In the legacy subsystem, HA policy is driven by 2 attributes on the hornetq-server resource (shared-store and backup which both are BOOLEAN attribute that allow expressions).
> In the new messaging-activemq subsystem, HA policy is configured by different child for the ha-policy resource (shared-store-slave, shared-store-master, replication-master, replication-slave and others).
> 
> During the migration, I can not just read the values of the share-store and backup attributes to determine the type of ha-policy to use in the new subsystems. If they use expressions, their values are determined by the system properties set for each server.

That’s detectable though right? If there is no expression is it mappable? 

> 
> That means that with previous versions, you could use 1 single profile to have both a master and slave nodes (with different sys prop for their backup attribute).
> In WildFly 10, there must be 2 different profile, one with replication-master and another with replication-slave.
> I think this goes beyond the scope of the :migrate operation to create multiple profiles during the migration of a single subsystem.

Yes creating profiles is definitely out of scope. 

> 
> I’d prefer to warn the user that messaging HA configuration has significantly changed and he will have to review the legacy one and configure a new one.
> We can then use higher-level tools (such a JBoss WindUp) to help him configure the new ones.

Note that Windup is likely (but not yet certain) to use the migration operations itself. 

> 
> The migration sequence in that case would be:
> 
> 1. call /subsystem=messaging:describe-migration to check if there are any warnings
> 2. if there are (e.g. about this HA stuff), run WindUp to create XML snippet (or CLI commands)   
>   corresponding to the HA stuff (I’ve no idea how WindUp can do that, so I’m just waving my hands and 
>   assume it can)
> 3. call /subsystem=messaging:migrate
> => the legacy messaging subsystem has been removed and the new messaging-activemq is present without its HA configuration
> 4. use the WindUp output (copy the XML snippet or execute the CLI commands) to add the new HA configuration.
> 
> Is that something doable with WindUp?

The windup team is relying on us for domain expertise, so if it does anything super fancy in this area, beyond the operation, that would probably rely on some sort of contribution from our team.
 
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat