[wildfly-dev] Migration management operation - open questions

Ladislav Thon lthon at redhat.com
Wed Aug 12 03:14:30 EDT 2015


Inline.

>> I believe that the :migrate operations _could_ return these warnings in
>> the operation result, but since Brian thinks that this is problematic,
>> I'll have to leave the details up to you, guys :-)
>>
> 
> It can be done, and IMHO must be done if the handler is ignoring aspects 
> of the migrated configuration.

100% agreed.

> It just means altering the format of the 
> result of both the "migrate" and "describe-migration" operations.
> 
> The "warnings" can only be for items identified by the migration op 
> handler directly. If any of the various add/remove ops that that handler 
> tells the controller to execute fail, then the overall result will be a 
> failure. That is, no attempt to hack into the handling of those ops and 
> convert that kind of failure into a "warn".

I think this is expected and I'm fine with it.

> I propose the following format for the "result" field of the migrate 
> operation response:
> 
> {
>    "migration-warnings"=>[
>      "WFXXX1234: the blah is blah",
>      "WFXXX2345: the foo is barred"
>     ]
> }

The "result" field currently contains a name and version of newly
created subsystem, which should probably be preserved:

[standalone at localhost:9990 /] /subsystem=jacorb:migrate
{
    "outcome" => "success",
    "result" => [("iiop-openjdk" => "1.0.0")]
}

> For "describe-migration":
> 
> 
> 
> {
>   "migration-warnings"=>[
>    "WFXXX1234: the blah is blah",
>    "WFXXX2345: the foo is barred"
>   ],
>   "migration-operations=>[
>    { an operation },
>    { another operation}
>   ]
> }
> 
> The value of the "migration-operations" field would be the same as the 
> overall result value currently produced by these ops.

Sounds good.

LT


More information about the wildfly-dev mailing list