[wildfly-dev] Migration management operation - open questions

[Brian Stansberry]

On 8/11/15 1:39 AM, Ladislav Thon wrote:
> I agree 100% with a single note: before "they can fix up any issues",
> they have to know that there are issues. If the :migrate operation knows
> that there will be issues (e.g. valves present in the old subsystem), it
> would be _very nice_ if it provided a warning :-) The earlier is the
> user aware of [possible] issues, the better.
>
> 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. 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 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"
    ]
}

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.

> LT
>
> On 11.8.2015 04:05, Stuart Douglas wrote:
>> I don't think it should fail, imagine how frustrating that would be from
>> a users perspective, as the only course of action they have is to delete
>> the relevant resource and try again. It would be much more user friendly
>> IMHO to just let the op complete and then they can fix up any issues,
>> they will still end up in the same situation, just with less work on
>> their part.
>>
>> Stuart
>>
>>
>>
>> On Tue, 11 Aug 2015 at 10:40 Jason Greene <jason.greene at redhat.com
>> <mailto:jason.greene at redhat.com>> wrote:
>>
>>
>>>      On Aug 10, 2015, at 5:23 PM, Stuart Douglas
>>>      <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>>
>>>      wrote:
>>>
>>>
>>>          > 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
>>>          > -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
>>>          >
>>>
>>>          I'll let Stuart respond to this. Looking at the
>>>          WebMigrateOperation (the
>>>          handler for the web subsystem migrate op) it looks to be adding a
>>>          security realm.
>>>
>>>
>>>      Yes, at the moment I do create new security realms, and also add
>>>      the IO subsystem with a default config if it is not already
>>>      present. The names for the security realm will
>>>      be jbossweb-migration-security-realm(n), where n is the lowest
>>>      number that does not result in a name collision.
>>>
>>
>>      As an example of the fail-or-warn question, unless I am reading the
>>      code wrong, it looks like things which don’t have a mapping (e.g.
>>      tomcat valves) are ignored. Should the migration op fail if one is
>>      used, or should it return a warning?
>>
>>      --
>>      Jason T. Greene
>>      WildFly Lead / JBoss EAP Platform Architect
>>      JBoss, a division of Red Hat
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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