4:01 a.m.
On 10 Aug 2015, at 17:08, Brian Stansberry
<brian.stansberry(a)redhat.com> 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.
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 means that with previous versions, you could use 1 single profile to have both a
master and slave nodes (with different sys prop for their backup attribute).
In WildFly 10, there must be 2 different profile, one with replication-master and another
with replication-slave.
I think this goes beyond the scope of the :migrate operation to create multiple profiles
during the migration of a single subsystem.
I’d prefer to warn the user that messaging HA configuration has significantly changed and
he will have to review the legacy one and configure a new one.
We can then use higher-level tools (such a JBoss WindUp) to help him configure the new
ones.
The migration sequence in that case would be:
1. call /subsystem=messaging:describe-migration to check if there are any warnings
2. if there are (e.g. about this HA stuff), run WindUp to create XML snippet (or CLI
commands)
corresponding to the HA stuff (I’ve no idea how WindUp can do that, so I’m just waving
my hands and
assume it can)
3. call /subsystem=messaging:migrate
=> the legacy messaging subsystem has been removed and the new messaging-activemq is
present without its HA configuration
4. use the WindUp output (copy the XML snippet or execute the CLI commands) to add the new
HA configuration.
Is that something doable with WindUp?
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/