[wildfly-dev] Management operation for legacy subsystem migration

[Jason T. Greene]

Instead of hard errors, and manipulating the old model, wouldn't it be better to just convert and then report back in the response what was dropped? 

The outcome is the same right, but with just less steps.

If we are worried about config data loss or something like that, the dry run option cold be he default.

> On Apr 29, 2015, at 9:01 AM, Jeff Mesnil <jmesnil at redhat.com> wrote:
> 
> With WildFly 9 and 10, we will have new subsystems that will replace some older subsystems (called legacy subsystems below).
> 
> We have to deal with migrating these subsystems:
> 
> * migrate from web (JBoss Web)     to undertow
> * migrate from messaging (HornetQ) to messaging-activemq (with Apache ActiveMQ Artemis)
> * migrate from jacorb              to iiop-openjdk
> 
> These 3 tasks are about providing a management operation to perform one-time migration (i.e. the migration is an operation performed by the server on its management model).
> 
> I have started to look at this from the messaging perspective.
> 
> To constrain this task, I have added some requirements:
> 
> 1. the legacy subsystem must be an empty shell and has no runtime
> => in WildFLy 10, /subsystem=messaging is only exposing its management model but there is no runtime (HornetQ server library is not included)
> 2. the server must be in admin-only mode during migration
> => the server is not serving any client during migration.
> => the migration deals only with the server management model by creating the model for the new subsystem based on the legacy subsystem's model
> 3. Data are not moved during this migration operation
> => moving messages from HornetQ to ActiveMQ destinations is not performed during this management migration.
> => we already have process (such as using JMS bridges) to move messages from one messaging provider to another
> 
> Having these three requirements simplifies the migration task and sounds reasonable.
> Do you foresee any issues with having them?
> 
> Given these requirements, the legacy subsystem would need to expose a :migrate operation (at the root of the subsystem) to perform the actual migration of the management model.
> 
> Its pseudo code would be something like:
> 
> * check the server is in admin-only mode
> defined any child resource)
> * :describe the legacy subsystem model
> * transform the legacy subsystem description to the new subsystem
> => if everything is successful
>  * create a composite operation to add the new messaging-activemq extension and all the transformed :add operations
>  * report the composite operation outcome to the user
> => else
>  * report the error(s) to the user
> 
> It is possible that the legacy subsystem can not be fully migrated (e.g. if it defines an attribute that has no equivalent on the new subsystem). In that case, the :migrate operation reports the error(s) to the user.
> The user can then change the legacy subsystem model to remove the problematic resource/attributes and invoke :migrate again
> 
> For the messaging subsystem, I expect that it will not be possible to fully migrate the replication configuration of the legacy subsystem to the new subsystem (the configuration has significantly changed between HornetQ and ActiveMQ, some configuration will be incompatible).
> In that case, I'd expect the user to migrate to the new messaging-activemq subsystem by discarding the legacy subsystem's replication configuration, invoke :migrate and then configure replication for the new subsystem.
> 
> In my proof of concept, the :migrate operation has a dry-run boolean attribute. If set to true, the operation will not run the composite operation. It will instead return to the user the list of operations that will be executed when the :migrate operation is actually performed.
> 
> I have talked to Tomek which is charge of the iiop migration and he has an additional requirement to emulate the legacy jacorb subsystem with the new iioop-openjdk subsystem. I have not this requirement for the messaging subsystem so I have not given much thought about it...
> Same goes for the web -> undertow migration.
> 
> It's also important to note that this operation to migrate the management model of a legacy subsystem to a new one is only one step of the whole migration story.
> For messaging, the workflow to upgrade an WFLY 9 server to WFLY 10 is made of several other steps (and I may have forgotten some)
> 
> * install the new server
> * copy the old configuration (with the legacy messaging subsystem)
> * start the new server in admin-only mode
> * invoke /subsystem=messaging:migrate
>  => rinse and repeat by tweaking the legacy subsystem until the migration is successful
> * if migration of data can be done offline, do it now (the server is in admin-only mode, so it's ok)
> * reload the server to return to running mode with the new messaging subsystem
> * if the migration of data must be done offline, it can be done now
>  (e.g. create a new JMS bridge from the old running WFLY9/messaging server to this new WFLY10/messaging-activemq server)
> * if everything is fine, invoke /subsystem=messaging:remove to remote the legacy subsystem model.
> 
> Any comment, critic, feedback?
> 
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev