[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