[jboss-jira] [JBoss JIRA] (WFLY-8854) Clean up managed domain handling of messaging-activemq broadcast-group and cluster-connection runtime-only ops
Brian Stansberry created WFLY-8854:
--------------------------------------
Summary: Clean up managed domain handling of messaging-activemq
broadcast-group and cluster-connection runtime-only ops
Key: WFLY-8854
URL: https://issues.jboss.org/browse/WFLY-8854
Project: WildFly
Issue Type: Sub-task
Components: JMS
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
Subtask for the following items from the parent issue:
{quote}
8) The messaging-activemq broadcast-group resource has problematic 'start' and
'stop' ops. These are not registered as runtime-only, but they are. They are
registered on the profile resource and are not read-only, so the DC rolls them out to the
domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that
WFCORE-389 is about rescinding. We have two
options here:
a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule.
This would be a breaking change. But it may be the correct thing to do anyway if it is
unsafe to invoke these on the profile and have that roll out to all servers.
b) Correct the description of these to declare runtime-only.
{quote}
Task for this is to make a decision.
{quote}
9) The messaging-activemq broadcast-group resource also has problematic a
get-connector-pairs-as-json op. This is a read-only op so it currently will not roll out.
It will also fail if executed against the profile resource, as it fails if there is no
activemq server present. So, the options here are:
a) Remove the op from the profile resource. It never worked anyway.
b) Allow them to roll out. This would be new behavior though.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent
that rollout.
IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid
"emergency" step to prevent roll out inadvertently being turned on while a
decision between a) and b) is made. So that's what will be done as part of this work.
{quote}
As part of the parent task, option c) will be put in place. Task here is to decide final
resolution.
{quote}
10) The messaging-activemq cluster-connection resource has problematic 'start' and
'stop' ops. These are not registered as runtime-only, but they are. They are
registered on the profile resource and are not read-only, so the DC rolls them out to the
domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that
WFCORE-389 is about rescinding. We have two
options here:
a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule.
This would be a breaking change. But it may be the correct thing to do anyway if it is
unsafe to invoke these on the profile and have that roll out to all servers.
b) Correct the description of these to declare runtime-only.
{quote}
Nothing was done re: this in the parent task.
{quote}
11) The messaging-activemq cluster-connection resource also has problematic a get-nodes
op. This is a read-only op so it currently will not roll out. It will also fail if
executed against the profile resource, as it fails if there is no activemq server present.
So, the options here are:
a) Remove the op from the profile resource. It never worked anyway.
b) Allow them to roll out. This would be new behavior though.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent
that rollout.
IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid
"emergency" step to prevent roll out inadvertently being turned on while a
decision between a) and b) is made. So that's what will be done as part of this work.
{quote}
As part of the parent task, option c) will be put in place. Task here is to decide final
resolution.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)