[wildfly-dev] Migration management operation - open questions

[Stuart Douglas]

On Tue, 11 Aug 2015 at 17:59 Ladislav Thon <lthon at redhat.com> wrote:

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

These are bugs. EJB and datasources are still very much supported, I am
going to look into this.

Stuart



>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150811/b0b2275d/attachment.html