Re: [wildfly-dev] Management operation for legacy subsystem migration

On 29 Apr 2015, at 16:58, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: On 4/29/15 9:00 AM, Jeff Mesnil 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) I don't see why this needs to be a requirement. In the jacorb case, it will be violated, as the jacorb subsystem can run as a kind of "compatibility subsystem", delegating to the iiop-openjdk runtime services as long as the config doesn't specify any settings that can't be translated.

There needs to be validation as to whether the extension is already present; if so skip the add. This is an edge case on a server but is fairly likely on a DC, where the extension may be used in profile-new, and now the users wants to migrate the subsystem in profile-old.

Also, we're going to need to change how the "composite" op works, as including an extension=foo:add in the same composite as steps that touch its subsystems won't work. There's a JIRA for this, but JIRA doesn't seem to be responding at the moment. There's a workaround for that issue if necessary; just have the migrate op add a step that deals with the extension add and then a next step with the composite.

> 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. > The return value should be the same regardless of the value of that attribute. Ops have single return value description.

We need to be careful about RBAC. This basically amounts to one op that then convinces the server to do a whole bunch of other stuff.