[wildfly-dev] Management operation for legacy subsystem migration

[Brian Stansberry]

On 4/30/15 9:03 AM, Jeff Mesnil wrote:
> comments embedded.
>
>> On 29 Apr 2015, at 16:58, Brian Stansberry <brian.stansberry at redhat.com> 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.
>
> You are right, this is not a requirement. It’s specific to the legacy messaging subsystem and is not related to the generic migrate operation of legacy subsystem.
>
>> 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.
>
> Ok, I’ll add this check.
>
>>
>> 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.
>
> Ok, that’s what I did in my POC[1]. I was not sure if it was a bug or not.
>
> The JIRA should be https://issues.jboss.org/browse/WFCORE-323.
> You even used the messaging subsystem for its example :)
>
>>
>>> 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.
>
> Good point. In that case, the :migrate operation will return the outcome of the migration operation.

What would that be? If the describe-migration is a separate op, then I 
figure for this op, the response would be

{"outcome"=>"success","result"=>undefined}

> And I can add a :describe-migration that lists the required operations.
>
>> 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.
>
> This :migrate operation is using the outcome of the :describe operation on the legacy subsystem (which has a READ_WHOLE_CONFIG access constraint) and execute :add operations.
> Do we need to flag it specifically or are its constraints the byproduct of the :describe and :add operations constraints?
>

So this basically means these ops would be limited to SuperUser or 
Administrator (unless the users change the settings for READ_WHOLE_CONFIG.)

I'd forgotten that "describe" worked that way.

The constraints would be a byproduct, but we should flag the op anyway, 
otherwise it's unintuitive. The metadata for the op inform the user of 
the effective constraint. Plus if we're not careful the user may end up 
getting a failure message saying they aren't authorized to run the 
"describe" op when they didn't request that op.

> jeff
>
> [1] https://github.com/jmesnil/wildfly/blob/messaging-activemq-xml/messaging/src/main/java/org/jboss/as/messaging/MigrateOperation.java#L119
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat