> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode? > I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this part. Ideally this would be covered somewhere in https://docs.jboss.org/author/display/WFLY10/Documentation. The intent is all three of these have common semantics. The biggest thing is these ops all require that the target process is running in --admin-only mode.

> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning? > -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding? > The migrate operation is used to migrate a valid configuration. What you describe is an invalid configuration, as the needed socket-binding is not present.

The migration operation should not remove external configuration (e.g. remove a socket-binding), as the ability to determine what other uses there may be in the overall config for that config is beyond the scope of the migration op handler.

> 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.

> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? > I think the op should fail (not just warn) if the subsystem cannot be properly migrated.

That said, we need to be careful about having the scope of the handlers grow too large, forcing handlers for one subsystem to be tightly coupled to the implementation details of other subsystems or the kernel. Your questions 2-4 relate to this kind of scope question. If the coupling between different parts of the system starts to get too deep, IMO it starts to move beyond the intended scope of these operations and into the realm of higher level tools like Red Hat's Windup tool. It's a judgement call but my feeling is what the handlers are currently doing (e.g. the stuff I mention in my answer to #2) is reasonable.

> 6. Should the extensions for old subsystems be left in configuration after migration? > In a domain, yes. The migration of a subsystem in one profile does not mean the extension is unavailable for use in another profile. I don't have a strong opinion about this in standalone. I do suspect there may be a technical barrier to removing the extension though. If so I doubt we'll do it in WildFly 10.

> 7. Should the :migrate operation return reload-required header? > The migrate operations function by executing operations to add and remove resources. If those operations themselves put the process in reload-required, then the header will be returned. If not, it won't. The migrate operations all require that the process be running in --admin-only mode. So I would not expect the outcome to be a need to put the process in reload-required. Most likely that outcome would be a bug. We use reload-required when changes to the persistent configuration cannot be reflected in existing running services, but in --admin-only there are no running services associated with these subsystems.

On Aug 10, 2015, at 11:33 AM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: On 8/10/15 10:59 AM, Ladislav Thon wrote: > Brian, thanks for answering. I'll clarify some qustions below (and I > hope that others from our team will join too). > >>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode? >>> >> >> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this >> part. Ideally this would be covered somewhere in >> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent >> is all three of these have common semantics. >> >> The biggest thing is these ops all require that the target process is >> running in --admin-only mode. > > This is mostly about clarifying what should I do before starting the new > server in --admin-only. > > In standalone -- am I supposed to copy snippets from old standalone.xml > to new standalone.xml? > > In domain -- uh oh, sorry, I don't really know, maybe this is somehow > connected to the ability of newer domain controller to manage older servers? > The intent here was not to let people start with a new standard config shipped by us and then use these ops to import stuff from a previous config. The expectation is they are starting with their existing config and changing it. It's possible they'll want to start with some sort of a hybrid, i.e. take our new standard config, then bring their own stuff in, and then let us migrate parts. If so the user is responsible for creating that initial hybrid. If some other tooling helps them with that, all the better, but that's out of scope for these ops. >>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning? >>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding? >>> >> >> The migrate operation is used to migrate a valid configuration. What you >> describe is an invalid configuration, as the needed socket-binding is >> not present. > > So if the migration approach is to "copy all required snippets from old > configuration to the new one", I have to copy all dependencies (e.g. > socket bindings) too. Makes sense, though maybe we had a different > situation in mind here that I can't recollect now... :-( > >> The migration operation should not remove external configuration (e.g. >> remove a socket-binding), as the ability to determine what other uses >> there may be in the overall config for that config is beyond the scope >> of the migration op handler. > > Sure. > >>> 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. > > This is probably the right thing to do, but we wanted to be sure. We've > seen some possible problems with this (e.g. name collisions), so we > thought that it's better to ask :-) > It's a good question. They all are. :) What WebMigrateOperation does is create a synthetic realm name by starting with a base name and adding a digit, looping and incrementing the digit until it finds a name that doesn't collide. >>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? >>> >> >> I think the op should fail (not just warn) if the subsystem cannot be >> properly migrated. > > I can agree both with this and with the other approach of "it's probably > easier for the user to fixup the new subsystem then it is to repeatedly > alter the old subsystem until you get something that will convert" [1]. > > [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html > > The idea here is that if the :migrate operation can see a possible > problem, then the problem must be reported during :migrate and not only > when the migrated server is started for the first time. Of course I > agree with Good point. I'll let Jason and the guys who actually wrote these respond further.

The idea of warning is problematic. Management ops return a result or a failure, not a result + a warning. We can of course warn in the server log, but I think it's dangerous to reply with a success result and then count on the possibly-remote user to notice a server log message.

> This is mostly about clarifying what should I do before starting the new > server in --admin-only. > > In standalone -- am I supposed to copy snippets from old standalone.xml > to new standalone.xml? > > In domain -- uh oh, sorry, I don't really know, maybe this is somehow > connected to the ability of newer domain controller to manage older servers? > The intent here was not to let people start with a new standard config shipped by us and then use these ops to import stuff from a previous config. The expectation is they are starting with their existing config and changing it.

It's possible they'll want to start with some sort of a hybrid, i.e. take our new standard config, then bring their own stuff in, and then let us migrate parts. If so the user is responsible for creating that initial hybrid. If some other tooling helps them with that, all the better, but that's out of scope for these ops.

Inline. >> This is mostly about clarifying what should I do before starting the new >> server in --admin-only. >> >> In standalone -- am I supposed to copy snippets from old standalone.xml >> to new standalone.xml? >> >> In domain -- uh oh, sorry, I don't really know, maybe this is somehow >> connected to the ability of newer domain controller to manage older servers? >> > > The intent here was not to let people start with a new standard config > shipped by us and then use these ops to import stuff from a previous > config. The expectation is they are starting with their existing config > and changing it. So this is in some ways the most important part of this discussion :-) I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10 Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension 'org.jboss.as.threads' is not supported on servers running this version." Removed the extension, started again, failed with "Unexpected element '{urn:jboss:domain:threads:1.1}subsystem'" (of course!). Removed the "threads" subsystem, started again, failed with two error messages related to the "datasources" and "ejb3" subsystems. Is this the intended workflow? I didn't get further, because I somehow get a feeling that patching the new default configuration with relevant bits from the old one will be easier when only a handful of changes in the configuration were made, and probably on-par when the configuration changes were more involved. Of course it's just a feeling, but the first impression is important too :-)

> It's possible they'll want to start with some sort of a hybrid, i.e. > take our new standard config, then bring their own stuff in, and then > let us migrate parts. If so the user is responsible for creating that > initial hybrid. If some other tooling helps them with that, all the > better, but that's out of scope for these ops. Of course, no question about that. LT _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

I think it makes sense to make a requirement that the user should not have to do anything before starting in --admin-only.

On Wed, Aug 12, 2015 at 9:18 AM, Ladislav Thon <lthon(a)redhat.com <mailto:lthon@redhat.com>> wrote: However, if there's not enough time to do everything requried, then I believe that low-risk things like "remove the threads extension and the threads subsystem" could be left to the user (provided that they are documented). I think we could ease the threads subsystem migration. For most cases threads subsystem configuration is empty as it was just present in our default config as <subsystem xmlns="urn:jboss:domain:threads:1.x"/> We can change parser that in case that only empty config is present it wont add the subsystem at all, this should ease the migration for users migrating default configurations.

_______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

https://github.com/wildfly/wildfly-core/pull/953 is a big (and quite simple) step.

In a domain, yes. The migration of a subsystem in one profile does not mean the extension is unavailable for use in another profile. I don't have a strong opinion about this in standalone.

On Aug 10, 2015, at 5:23 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; 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.

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(a)redhat.com <mailto:jason.greene@redhat.com>> wrote: > On Aug 10, 2015, at 5:23 PM, Stuart Douglas > <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

> 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.

> 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 current implementation use a composite operation, so the results look like: /subsystem=web:migrate { "outcome" => "success", "result" => { "step-1" => {"outcome" => "success"}, "step-2" => {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, .... } } Because this is using a composite op, I am not sure how the migration-warnings should be displayed? Possibly as the results of the first step? Stuart > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

> The approach I took was to add the warnings to the describe-migration > op, and when running the migrate op make the describe-migration > operation the first step in the composite, so the output looks like > this: http://pastebin.com/B01KNAHX The fact that it's a composite operation makes the output a bit cryptic (step-X?), but otherwise I think it's actually good. I guess that only handling the warnings in :describe-migration makes the implementation easier (not sure?) and printing :describe-migration as a part of :migrate makes sense too, precisely because it shows the steps that are performed. So my only objection would be those cryptic "step-X" names, but I guess that we can live with that (if all :migrate operations took the same approach; inconsistency wouldn't really help here).

LT _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 8/13/15 3:11 AM, Stuart Douglas wrote: > > > On Thu, 13 Aug 2015 at 16:27 Ladislav Thon <lthon(a)redhat.com > <mailto:lthon@redhat.com>> wrote: > > > > The approach I took was to add the warnings to the describe-migration > > op, and when running the migrate op make the describe-migration > > operation the first step in the composite, so the output looks like > > this: http://pastebin.com/B01KNAHX > > The fact that it's a composite operation makes the output a bit cryptic > (step-X?), but otherwise I think it's actually good. > > I guess that only handling the warnings in :describe-migration makes the > implementation easier (not sure?) and printing :describe-migration as a > part of :migrate makes sense too, precisely because it shows the steps > that are performed. > > So my only objection would be those cryptic "step-X" names, but I guess > that we can live with that (if all :migrate operations took the same > approach; inconsistency wouldn't really help here). > > > That is because this is implemented as a composite operation, AFAIK > there is lots of special handing for composite ops, so I don't think we > want to be implementing our own one with different output just for this > case. > > I could be wrong though, this is not really my area, Brian will know more. > In the success case, I don't see the point of outputting "step-2" => {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, etc. In the failure case though, having an intelligible failure-description is important. And the composite op handler may be getting in your way there Instead of writing more text, I'll write some code to illustrate some thoughts and post back later.

> Stuart > > > LT > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

[standalone@localhost:9999 /] /subsystem=web:migrate { "outcome" => "success", "result" => {"migration-warnings" => []} }

I have a PR that builds on Brian's work for the web migrate op: https://github.com/wildfly/wildfly/pull/7931 Output is: Standard EAP config (no warnings or errors): [standalone@localhost:9999 /] /subsystem=web:migrate { "outcome" => "success", "result" => {"migration-warnings" => []} } Success with a warning (in this case due to an invalid protocol attribute on a connector): [standalone@localhost:9999 /] /subsystem=web:migrate { "outcome" => "success", "result" => {"migration-warnings" => ["WFLYWEB0002: Could not migrate resource { \"protocol\" => \"INVALID\", \"scheme\" => \"http\", \"socket-binding\" => \"ajp\", \"enable-lookups\" => undefined, \"proxy-binding\" => undefined, \"proxy-name\" => undefined, \"proxy-port\" => undefined, \"redirect-binding\" => undefined, \"redirect-port\" => undefined, \"secure\" => undefined, \"max-post-size\" => undefined, \"max-save-post-size\" => undefined, \"enabled\" => undefined, \"executor\" => undefined, \"max-connections\" => undefined, \"virtual-server\" => undefined, \"name\" => \"ajp\", \"operation\" => \"add\", \"address\" => [ (\"subsystem\" => \"web\"), (\"connector\" => \"ajp\") ] }"]} } Failed OP: [standalone@localhost:9999 /] /subsystem=web:migrate { "outcome" => "failed", "result" => { "migration-warnings" => [], "migration-error" => { "operation" => { "operation" => "add", "address" => [ ("subsystem" => "undertow"), ("server" => "default-server"), ("ajp-listener" => "ajp") ], "socket-binding" => "ajp", "secure" => undefined, "redirect-socket" => undefined, "enabled" => undefined, "resolve-peer-address" => undefined, "max-post-size" => undefined, "max-connections" => "sadfadsfasdgasdfg", "operation-headers" => { "caller-type" => "user", "access-mechanism" => "NATIVE" }, "worker" => undefined, "buffer-pool" => undefined, "disallowed-methods" => undefined, "max-header-size" => undefined, "buffer-pipelined-data" => undefined, "max-parameters" => undefined, "max-headers" => undefined, "max-cookies" => undefined, "allow-encoded-slash" => undefined, "decode-url" => undefined, "url-charset" => undefined, "always-set-keep-alive" => undefined, "max-buffered-request-size" => undefined, "record-request-start-time" => undefined, "allow-equals-in-cookie-value" => undefined, "no-request-timeout" => undefined, "request-parse-timeout" => undefined, "tcp-backlog" => undefined, "receive-buffer" => undefined, "send-buffer" => undefined, "tcp-keep-alive" => undefined, "read-timeout" => undefined, "write-timeout" => undefined }, "result" => { "outcome" => "failed", "failure-description" => "WFLYCTL0097: Wrong type for max-connections. Expected [INT] but was STRING", "rolled-back" => true } } }, "rolled-back" => true } Stuart On Fri, 14 Aug 2015 at 11:03 Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: On 8/13/15 10:03 AM, Brian Stansberry wrote: > On 8/13/15 3:11 AM, Stuart Douglas wrote: >> >> >> On Thu, 13 Aug 2015 at 16:27 Ladislav Thon <lthon(a)redhat.com <mailto:lthon@redhat.com> >> <mailto:lthon@redhat.com <mailto:lthon@redhat.com>>> wrote: >> >> >> > The approach I took was to add the warnings to the describe-migration >> > op, and when running the migrate op make the describe-migration >> > operation the first step in the composite, so the output looks like >> > this: http://pastebin.com/B01KNAHX >> >> The fact that it's a composite operation makes the output a bit cryptic >> (step-X?), but otherwise I think it's actually good. >> >> I guess that only handling the warnings in :describe-migration makes the >> implementation easier (not sure?) and printing :describe-migration as a >> part of :migrate makes sense too, precisely because it shows the steps >> that are performed. >> >> So my only objection would be those cryptic "step-X" names, but I guess >> that we can live with that (if all :migrate operations took the same >> approach; inconsistency wouldn't really help here). >> >> >> That is because this is implemented as a composite operation, AFAIK >> there is lots of special handing for composite ops, so I don't think we >> want to be implementing our own one with different output just for this >> case. >> >> I could be wrong though, this is not really my area, Brian will know more. >> > > In the success case, I don't see the point of outputting "step-2" => > {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, etc. > > In the failure case though, having an intelligible failure-description > is important. And the composite op handler may be getting in your way there > > Instead of writing more text, I'll write some code to illustrate some > thoughts and post back later. > Here's what I was thinking. [1] is a change to break out the step registration stuff CompositeOperationHandler does into a utility method, with a couple other variants added that are better suited for use by other OSHs. Basically, it lets you pass in a Map of ops and a holder map of response nodes, and it will add the steps and populate the response node map. (You can optionally pre-populate the response node map. There's also a variant that uses lists instead of maps in case that's more convenient.) Using that, the response nodes for the added ops don't have to directly appear in the overall operation response. Instead the migrate op handler can hold a ref to them and in its ResultHandler use them to format an understandable response. The top two commits in [2] are an example tweak to the current WebMigrationOp in master to illustrate use of this. [1] https://github.com/wildfly/wildfly-core/pull/956 [2] https://github.com/bstansberry/wildfly/tree/help-migrate-multistep >> Stuart >> >> >> LT >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Sat, 15 Aug 2015 at 01:01 Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: Looks good. Do we want migration-warnings=-[] in the success case, or just omit it? I don't have a strong preference either way. I have changed it so this will not be displayed. Seeing all the details in the failure case made me nervous about RBAC. But I think the key there is in the read of the subsystem that goes to produce the ops. We should test that that fails if the caller is not able to address some child resource or if the caller is not able to read some attribute value. Should this hold up the PR, or is this a task for later?

Stuart If we know the caller can read the entire subsystem then it is safe to provide details of any failure on the writes, since it is the same data. Once everything is clear we should work out a way to have shared code so this stuff has a higher guarantee of consistency across subsystems. On 8/14/15 1:32 AM, Stuart Douglas wrote: > I have a PR that builds on Brian's work for the web migrate op: > https://github.com/wildfly/wildfly/pull/7931 > > Output is: > > Standard EAP config (no warnings or errors): > > [standalone@localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "success", > "result" => {"migration-warnings" => []} > } > > Success with a warning (in this case due to an invalid protocol > attribute on a connector): > > [standalone@localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "success", > "result" => {"migration-warnings" => ["WFLYWEB0002: Could not > migrate resource { > \"protocol\" => \"INVALID\", > \"scheme\" => \"http\", > \"socket-binding\" => \"ajp\", > \"enable-lookups\" => undefined, > \"proxy-binding\" => undefined, > \"proxy-name\" => undefined, > \"proxy-port\" => undefined, > \"redirect-binding\" => undefined, > \"redirect-port\" => undefined, > \"secure\" => undefined, > \"max-post-size\" => undefined, > \"max-save-post-size\" => undefined, > \"enabled\" => undefined, > \"executor\" => undefined, > \"max-connections\" => undefined, > \"virtual-server\" => undefined, > \"name\" => \"ajp\", > \"operation\" => \"add\", > \"address\" => [ > (\"subsystem\" => \"web\"), > (\"connector\" => \"ajp\") > ] > }"]} > } > > Failed OP: > > [standalone@localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "failed", > "result" => { > "migration-warnings" => [], > "migration-error" => { > "operation" => { > "operation" => "add", > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("ajp-listener" => "ajp") > ], > "socket-binding" => "ajp", > "secure" => undefined, > "redirect-socket" => undefined, > "enabled" => undefined, > "resolve-peer-address" => undefined, > "max-post-size" => undefined, > "max-connections" => "sadfadsfasdgasdfg", > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE" > }, > "worker" => undefined, > "buffer-pool" => undefined, > "disallowed-methods" => undefined, > "max-header-size" => undefined, > "buffer-pipelined-data" => undefined, > "max-parameters" => undefined, > "max-headers" => undefined, > "max-cookies" => undefined, > "allow-encoded-slash" => undefined, > "decode-url" => undefined, > "url-charset" => undefined, > "always-set-keep-alive" => undefined, > "max-buffered-request-size" => undefined, > "record-request-start-time" => undefined, > "allow-equals-in-cookie-value" => undefined, > "no-request-timeout" => undefined, > "request-parse-timeout" => undefined, > "tcp-backlog" => undefined, > "receive-buffer" => undefined, > "send-buffer" => undefined, > "tcp-keep-alive" => undefined, > "read-timeout" => undefined, > "write-timeout" => undefined > }, > "result" => { > "outcome" => "failed", > "failure-description" => "WFLYCTL0097: Wrong type for > max-connections. Expected [INT] but was STRING", > "rolled-back" => true > } > } > }, > "rolled-back" => true > } > > Stuart > > > > > On Fri, 14 Aug 2015 at 11:03 Brian Stansberry > <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com> <mailto:brian.stansberry@redhat.com <mailto:brian.stansberry@redhat.com>>> wrote: > > On 8/13/15 10:03 AM, Brian Stansberry wrote: > > On 8/13/15 3:11 AM, Stuart Douglas wrote: > >> > >> > >> On Thu, 13 Aug 2015 at 16:27 Ladislav Thon <lthon(a)redhat.com <mailto:lthon@redhat.com> > <mailto:lthon@redhat.com <mailto:lthon@redhat.com>> > >> <mailto:lthon@redhat.com <mailto:lthon@redhat.com> <mailto:lthon@redhat.com <mailto:lthon@redhat.com>>>> wrote: > >> > >> > >> > The approach I took was to add the warnings to the > describe-migration > >> > op, and when running the migrate op make the > describe-migration > >> > operation the first step in the composite, so the output > looks like > >> > this: http://pastebin.com/B01KNAHX > >> > >> The fact that it's a composite operation makes the output a > bit cryptic > >> (step-X?), but otherwise I think it's actually good. > >> > >> I guess that only handling the warnings in > :describe-migration makes the > >> implementation easier (not sure?) and printing > :describe-migration as a > >> part of :migrate makes sense too, precisely because it > shows the steps > >> that are performed. > >> > >> So my only objection would be those cryptic "step-X" names, > but I guess > >> that we can live with that (if all :migrate operations took > the same > >> approach; inconsistency wouldn't really help here). > >> > >> > >> That is because this is implemented as a composite operation, AFAIK > >> there is lots of special handing for composite ops, so I don't > think we > >> want to be implementing our own one with different output just > for this > >> case. > >> > >> I could be wrong though, this is not really my area, Brian will > know more. > >> > > > > In the success case, I don't see the point of outputting "step-2" => > > {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, etc. > > > > In the failure case though, having an intelligible > failure-description > > is important. And the composite op handler may be getting in your > way there > > > > Instead of writing more text, I'll write some code to illustrate some > > thoughts and post back later. > > > > Here's what I was thinking. > > [1] is a change to break out the step registration stuff > CompositeOperationHandler does into a utility method, with a couple > other variants added that are better suited for use by other OSHs. > > Basically, it lets you pass in a Map of ops and a holder map of response > nodes, and it will add the steps and populate the response node map. > (You can optionally pre-populate the response node map. There's also a > variant that uses lists instead of maps in case that's more convenient.) > > Using that, the response nodes for the added ops don't have to directly > appear in the overall operation response. Instead the migrate op handler > can hold a ref to them and in its ResultHandler use them to format an > understandable response. > > The top two commits in [2] are an example tweak to the current > WebMigrationOp in master to illustrate use of this. > > [1] https://github.com/wildfly/wildfly-core/pull/956 > > [2] https://github.com/bstansberry/wildfly/tree/help-migrate-multistep > > >> Stuart > >> > >> > >> LT > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>>> > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

> On 14 Aug 2015, at 08:32, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: > > I have a PR that builds on Brian's work for the web migrate op: https://github.com/wildfly/wildfly/pull/7931 > > Output is: > > Standard EAP config (no warnings or errors): > > [standalone@localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "success", > "result" => {"migration-warnings" => []} > } I wonder if we should generalize this and move the warnings outside the result. The warnings could go in the response headers for example as a LIST of STRING. The result output would be something like: { "outcome" : "success", "result" : { … } "response-headers" : [{ "warnings" : [ “warning 1”, “warning 2” ] }] } This would help our clients (CLI and HAL) handle them appropriately regardless of the invoked operation. And this would not “pollute” the operation’s result type.

jeff

On 10 Aug 2015, at 17:08, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? > I think the op should fail (not just warn) if the subsystem cannot be properly migrated. That said, we need to be careful about having the scope of the handlers grow too large, forcing handlers for one subsystem to be tightly coupled to the implementation details of other subsystems or the kernel. Your questions 2-4 relate to this kind of scope question. If the coupling between different parts of the system starts to get too deep, IMO it starts to move beyond the intended scope of these operations and into the realm of higher level tools like Red Hat's Windup tool. It's a judgement call but my feeling is what the handlers are currently doing (e.g. the stuff I mention in my answer to #2) is reasonable.

On 20 Aug 2015, at 20:06, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > > I have a such an use case where I can’t migrate feature from the legacy messaging subsystem to the new messaging-activemq subsystem. > > In the legacy subsystem, HA policy is driven by 2 attributes on the hornetq-server resource (shared-store and backup which both are BOOLEAN attribute that allow expressions). > In the new messaging-activemq subsystem, HA policy is configured by different child for the ha-policy resource (shared-store-slave, shared-store-master, replication-master, replication-slave and others). > > During the migration, I can not just read the values of the share-store and backup attributes to determine the type of ha-policy to use in the new subsystems. If they use expressions, their values are determined by the system properties set for each server. That’s detectable though right? If there is no expression is it mappable?