[JBoss JIRA] (ELY-1206) Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/ELY-1206?page=com.atlassian.jira.plugin.s... ]
Yeray Borges moved JBEAP-11182 to ELY-1206:
-------------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1206 (was: JBEAP-11182)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: Security)
Affects Version/s: 1.1.0.Beta47
(was: 7.1.0.DR17)
> Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
> -------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1206
> URL: https://issues.jboss.org/browse/ELY-1206
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Critical
>
> {{rotating-file-audit}} throws {{IllegalArgumentException}} if user tries to add a new {{rotating-audit-file}} and does not specify {{suffix}} property.
> Steps to reproduce: {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log)}}
> Following output is given in jboss-cli
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}},
> "rolled-back" => true
> }
> {code}
> and following one in server log:
> {code}
> 12:45:41,381 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.security-event-listener.rotating-audit: org.jboss.msc.service.StartException in service org.wildfly.security.security-event-listener.rotating-audit: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'
> at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:826)
> at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:634)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:605)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:580)
> at org.wildfly.security.audit.RotatingFileAuditEndpoint$Builder.setSuffix(RotatingFileAuditEndpoint.java:289)
> at org.wildfly.extension.elytron.AuditResourceDefinitions$2.lambda$getValueSupplier$2(AuditResourceDefinitions.java:235)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> 12:45:41,382 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 5) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("rotating-file-audit-log" => "rotating-audit")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}}
> {code}
> Note: there is an easy workaround - if user specifies {{suffix}} property then adding a new {{rotating-audit-file}} works fine, e.g. {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log,suffix=y-M-d)}} passes successfully.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-1206) Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/ELY-1206?page=com.atlassian.jira.plugin.s... ]
Yeray Borges updated ELY-1206:
------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/2425)
> Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
> -------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1206
> URL: https://issues.jboss.org/browse/ELY-1206
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Critical
>
> {{rotating-file-audit}} throws {{IllegalArgumentException}} if user tries to add a new {{rotating-audit-file}} and does not specify {{suffix}} property.
> Steps to reproduce: {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log)}}
> Following output is given in jboss-cli
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}},
> "rolled-back" => true
> }
> {code}
> and following one in server log:
> {code}
> 12:45:41,381 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.security-event-listener.rotating-audit: org.jboss.msc.service.StartException in service org.wildfly.security.security-event-listener.rotating-audit: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'
> at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:826)
> at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:634)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:605)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:580)
> at org.wildfly.security.audit.RotatingFileAuditEndpoint$Builder.setSuffix(RotatingFileAuditEndpoint.java:289)
> at org.wildfly.extension.elytron.AuditResourceDefinitions$2.lambda$getValueSupplier$2(AuditResourceDefinitions.java:235)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> 12:45:41,382 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 5) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("rotating-file-audit-log" => "rotating-audit")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}}
> {code}
> Note: there is an easy workaround - if user specifies {{suffix}} property then adding a new {{rotating-audit-file}} works fine, e.g. {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log,suffix=y-M-d)}} passes successfully.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-389) Alllow non persistent configuration(runtime) changes for server groups and domain using CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-389?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-389:
------------------------------------
Fix Version/s: 3.0.0.Beta24
(was: 3.0.0.CR1)
> Alllow non persistent configuration(runtime) changes for server groups and domain using CLI
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-389
> URL: https://issues.jboss.org/browse/WFCORE-389
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Shay Matasaro
> Assignee: Brian Stansberry
> Labels: EAP, domain-mode
> Fix For: 3.0.0.Beta24
>
>
> Using the CLI , It is currently not possible to make runtime config changes to multiple servers , unless you are using a roll-out plan
> One example is the ability to disable a mod-cluster context on multiple servers at once.
> Since this operation does not affect the persistent server config it is currently not supported.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8854) Clean up managed domain handling of messaging-activemq broadcast-group and cluster-connection runtime-only ops
by Brian Stansberry (JIRA)
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)
8 years, 11 months
[JBoss JIRA] (WFLY-8853) CachedConnectionManager custom operations are read-only
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8853:
--------------------------------------
Summary: CachedConnectionManager custom operations are read-only
Key: WFLY-8853
URL: https://issues.jboss.org/browse/WFLY-8853
Project: WildFly
Issue Type: Sub-task
Components: JCA
Reporter: Brian Stansberry
Assignee: Brian Stansberry
*CRITICAL: DO NOT IMPLEMENT THIS IF WFCORE-2828 IS NOT IN PLACE.* Otherwise existing behavior will regress.
Subtask for the following item from the parent issue:
{quote}
JcaCachedConnectionManagerDefinition.CcmOperations has two operations that are not declared to be read-only that are registered on the profile resource. So these are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. A twist with these is they seem to actually be read-only and should be described as such. But if we do that we must implement WFCORE-2858 to avoid breaking existing behavior.
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8852) Clean up managed domain handling of the transaction subsystem's 'probe' operation
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8852:
--------------------------------------
Summary: Clean up managed domain handling of the transaction subsystem's 'probe' operation
Key: WFLY-8852
URL: https://issues.jboss.org/browse/WFLY-8852
Project: WildFly
Issue Type: Sub-task
Components: Transactions
Reporter: Brian Stansberry
Assignee: Tom Jenkinson
Subtask for this item from the parent issue:
{quote}
The transaction subsystem's "probe" operation. A read-only, runtime-only op registered on the profile resource but which is functionally a no-op if invoked on the profile resource. But WFCORE-2858 would mean this now gets rolled out to all servers in the domain that use the profile, triggering an actual probe on all. So, if we do WFCORE-2858 we could:
a) Accept this, and let the op roll out. That should be an RFE though, with analysis that rolling it out would be harmless.
b) Remove the op from the profile. It never did anything useful (just a no-op that isn't rolled out) so removing it is only
a semi-breaking change.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
Choice c) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) and b) still options for the future, so that's what will be done as part of this work.
{quote}
The parent issue will do choice c); this issue is to decide the final status.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8851) Clean up managed domain handling of JSFImplListHandler
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8851:
--------------------------------------
Summary: Clean up managed domain handling of JSFImplListHandler
Key: WFLY-8851
URL: https://issues.jboss.org/browse/WFLY-8851
Project: WildFly
Issue Type: Sub-task
Components: JSF
Reporter: Brian Stansberry
Assignee: Farah Juma
Subtask for this item from the parent issue:
{quote}
The JSF subsystem's "list-active-jsf-impl" op. A read-only, runtime-only op that does runtime work (scanning modules) in Stage.MODEL on the profile resource. Lots of rules being broken! What this op does now if invoked against the profile is tell you what jsf impls are present on the DC. Which is not the same thing as telling you what impls are present on "the domain" since different hosts in the domain can have different sets of modules. So the op needs a rethink.
a) If we correct the Stage.MODEL problem, we can't do WFCORE-2849. So we need to choose between the two.
b) If we do WFCORE-2858, this op will now start getting rolled out to the domain servers resulting in getting data from all servers. This is arguably the correct behavior, as now the user learns the true situation in the domain, not just on the DC. But if we decide we don't want that we'll need to add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
c) If we do roll it out to the servers we can consider having it no longer do runtime work on the profile; i.e. don't analyze the DC, just the servers. That would remove the conflict with WFCORE-2849, but would be an incompatible change in behavior. I find it hard to believe anyone would be using this op in scripts though; not against the profile.
d) We could just stop registering it on the profile, but that's a loss of functionality.
Choice b) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) c) and d) still options for the future.
{quote}
The parent task is going to do choice b) as a temp thing; this task is decide about the rest.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8850) Correct runtime-only operations on profile resources
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8850:
--------------------------------------
Summary: Correct runtime-only operations on profile resources
Key: WFLY-8850
URL: https://issues.jboss.org/browse/WFLY-8850
Project: WildFly
Issue Type: Bug
Components: IIOP, JCA, JMS, JSF, mod_cluster, Naming, Security, Transactions, Web (Undertow)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Attachments: runtimeonlyops.txt
OVERVIEW:
WFCORE-389 and WFCORE-2858 are about supporting runtime-only ops on profile resources, something which we officially don't do (although there are violations of this policy as is shown below.) As part of the decision as to whether to complete WFCORE-389 and WFCORE-2858 for Core 3 / WildFly 11 I have performed an analysis of the existing runtime-only ops in WildFly, looking for any issues. This JIRA is about correcting those issues. The intent is to make initial changes that don't alter behavior in any negative way in order to allow WFCORE-389 and WFCORE-2858 to proceed, but to do them in such a way that if 389 and 2858 don't proceed there is no harm. For some items there will be a follow up issue to make further decisions.
I performed 3 searches for operations that declare themselves as runtime-only, looking for any aspect of their behavior that might be problematic for WFCORE-389. I created a document which I'll attach with the results. I put a classifier to the left of each item as a shorthand re: the status of the item..
CLASSIFIERS:
NP -- non-profile. Op is not used in profile resources, either because it is not registered in subsystems, is only in deployment=*/subsystem=x resources, or the subsystem does not register it in an HC. Any NP op is not relevant to WFCORE-389.
WR -- WRite. The op is not read-only.
WR? -- the op is not declared as read-only but seems to only being doing reads
AO -- the op is registered on the profile but execution is a no-op unless the process is admin only
RU? -- the op doesn't seem to really be runtime-only
!!! -- Miscellaneously problematic ops
FIXES:
1) A number of ops have WR?/NP classifiers. The NP means these aren't relevant to WFCORE-389 but correcting the metadata so they are declared as read-only is a useful minor task.
2) The "migrate" ops in web, jacorb and messaging. These are registered on the profile (allowing profile migration) but will fail if the process isn't admin-only. An admin-only HC has no slaves or servers, so this means no domain-rollout of this op, and hence WFCORE-389, is not relevant. This is all by design; it allows users to migrate the subsystem in a domain profile. However, there is a question about them declaring themselves runtime-only, since they modify config. Correcting this is another useful minor task.
3) The "describe-migration" ops. Same discussion as for "migrate" plus these don't seem to be write ops, so a minor useful side task is to correct the metadata to describe them as read-only.
4) ModClusterConfigResourceDefinition registers 4 ops as runtime-only that seem to be modifying configuration; i.e. they are not runtime-only. These have a tangential relationship to WFCORE-389 in that they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. I'm not aware of any issues reported about them so that's a tiny bit of additional evidence that the kernel can handle such ops. But, a subtask of this issue is to correct the metadata for these so they will not be affected by any subsequent changes related to runtime-only ops.
5) JcaCachedConnectionManagerDefinition.CcmOperations has two operations that are not declared to be read-only that are registered on the profile resource. So these are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. A twist with these is they seem to actually be read-only and should be described as such. But if we do that we must implement WFCORE-2858 to avoid breaking existing behavior.
Nothing will be done about these as part of this work, but I'll file an issue to get it sorted.
6) The JSF subsystem's "list-active-jsf-impl" op. A read-only, runtime-only op that does runtime work (scanning modules) in Stage.MODEL on the profile resource. Lots of rules being broken! What this op does now if invoked against the profile is tell you what jsf impls are present on the DC. Which is *not* the same thing as telling you what impls are present on "the domain" since different hosts in the domain can have different sets of modules. So the op needs a rethink.
a) If we correct the Stage.MODEL problem, we can't do WFCORE-2849. So we need to choose between the two.
b) If we do WFCORE-2858, this op will now start getting rolled out to the domain servers resulting in getting data from all servers. This is arguably the correct behavior, as now the user learns the true situation in the domain, not just on the DC. But if we decide we don't want that we'll need to add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
c) If we do roll it out to the servers we can consider having it no longer do runtime work on the profile; i.e. don't analyze the DC, just the servers. That would remove the conflict with WFCORE-2849, but would be an incompatible change in behavior. I find it hard to believe anyone would be using this op in scripts though; not against the profile.
d) We could just stop registering it on the profile, but that's a loss of functionality.
Choice b) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) c) and d) still options for the future.
7) The transaction subsystem's "probe" operation. A read-only, runtime-only op registered on the profile resource but which is functionally a no-op if invoked on the profile resource. But WFCORE-2858 would mean this now gets rolled out to all servers in the domain that use the profile, triggering an actual probe on all. So, if we do WFCORE-2858 we could:
a) Accept this, and let the op roll out. That should be an RFE though, with analysis that rolling it out would be harmless.
b) Remove the op from the profile. It never did anything useful (just a no-op that isn't rolled out) so removing it is only
a semi-breaking change.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
Choice c) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) and b) still options for the future, so that's what will be done as part of this work.
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.
Nothing will be done on these as part of this work, but a separate issue will be filed.
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.
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.
Nothing will be done on these as part of this work, but a separate issue will be filed.
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.
12) A number of ops are using withFlags(OperationEntry.Flag.RUNTIME_ONLY) instead of setRuntimeOnly(). The effect is the same so this is harmless but a minor useful side task is to switch to setRuntimeOnly(). That will make it easier to find these ops.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8849) Correct runtime-only operations on profile resources
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8849?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-8849:
-----------------------------------
Attachment: runtimeonlyops.txt
> Correct runtime-only operations on profile resources
> ----------------------------------------------------
>
> Key: WFLY-8849
> URL: https://issues.jboss.org/browse/WFLY-8849
> Project: WildFly
> Issue Type: Bug
> Components: IIOP, JCA, JMS, JSF, mod_cluster, Naming, Security, Transactions, Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Attachments: runtimeonlyops.txt
>
>
> OVERVIEW:
> WFCORE-389 and WFCORE-2858 are about supporting runtime-only ops on profile resources, something which we officially don't do (although there are violations of this policy as is shown below.) As part of the decision as to whether to complete WFCORE-389 and WFCORE-2858 for Core 3 / WildFly 11 I have performed an analysis of the existing runtime-only ops in WildFly, looking for any issues. This JIRA is about correcting those issues. The intent is to make initial changes that don't alter behavior in any negative way in order to allow WFCORE-389 and WFCORE-2858 to proceed, but to do them in such a way that if 389 and 2858 don't proceed there is no harm. For some items there will be a follow up issue to make further decisions.
> I performed 3 searches for operations that declare themselves as runtime-only, looking for any aspect of their behavior that might be problematic for WFCORE-389. I created a document which I'll attach with the results. I put a classifier to the left of each item as a shorthand re: the status of the item..
> CLASSIFIERS:
> NP -- non-profile. Op is not used in profile resources, either because it is not registered in subsystems, is only in deployment=*/subsystem=x resources, or the subsystem does not register it in an HC. Any NP op is not relevant to WFCORE-389.
> WR -- WRite. The op is not read-only.
> WR? -- the op is not declared as read-only but seems to only being doing reads
> AO -- the op is registered on the profile but execution is a no-op unless the process is admin only
> RU? -- the op doesn't seem to really be runtime-only
> !!! -- Miscellaneously problematic ops
> FIXES:
> 1) A number of ops have WR?/NP classifiers. The NP means these aren't relevant to WFCORE-389 but correcting the metadata so they are declared as read-only is a useful minor task.
> 2) The "migrate" ops in web, jacorb and messaging. These are registered on the profile (allowing profile migration) but will fail if the process isn't admin-only. An admin-only HC has no slaves or servers, so this means no domain-rollout of this op, and hence WFCORE-389, is not relevant. This is all by design; it allows users to migrate the subsystem in a domain profile. However, there is a question about them declaring themselves runtime-only, since they modify config. Correcting this is another useful minor task.
> 3) The "describe-migration" ops. Same discussion as for "migrate" plus these don't seem to be write ops, so a minor useful side task is to correct the metadata to describe them as read-only.
> 4) ModClusterConfigResourceDefinition registers 4 ops as runtime-only that seem to be modifying configuration; i.e. they are not runtime-only. These have a tangential relationship to WFCORE-389 in that they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. I'm not aware of any issues reported about them so that's a tiny bit of additional evidence that the kernel can handle such ops. But, a subtask of this issue is to correct the metadata for these so they will not be affected by any subsequent changes related to runtime-only ops.
> 5) JcaCachedConnectionManagerDefinition.CcmOperations has two operations that are not declared to be read-only that are registered on the profile resource. So these are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. A twist with these is they seem to actually be read-only and should be described as such. But if we do that we must implement WFCORE-2858 to avoid breaking existing behavior.
> Nothing will be done about these as part of this work, but I'll file an issue to get it sorted.
> 6) The JSF subsystem's "list-active-jsf-impl" op. A read-only, runtime-only op that does runtime work (scanning modules) in Stage.MODEL on the profile resource. Lots of rules being broken! What this op does now if invoked against the profile is tell you what jsf impls are present on the DC. Which is *not* the same thing as telling you what impls are present on "the domain" since different hosts in the domain can have different sets of modules. So the op needs a rethink.
> a) If we correct the Stage.MODEL problem, we can't do WFCORE-2849. So we need to choose between the two.
> b) If we do WFCORE-2858, this op will now start getting rolled out to the domain servers resulting in getting data from all servers. This is arguably the correct behavior, as now the user learns the true situation in the domain, not just on the DC. But if we decide we don't want that we'll need to add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
> c) If we do roll it out to the servers we can consider having it no longer do runtime work on the profile; i.e. don't analyze the DC, just the servers. That would remove the conflict with WFCORE-2849, but would be an incompatible change in behavior. I find it hard to believe anyone would be using this op in scripts though; not against the profile.
> d) We could just stop registering it on the profile, but that's a loss of functionality.
> Choice b) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) c) and d) still options for the future.
> 7) The transaction subsystem's "probe" operation. A read-only, runtime-only op registered on the profile resource but which is functionally a no-op if invoked on the profile resource. But WFCORE-2858 would mean this now gets rolled out to all servers in the domain that use the profile, triggering an actual probe on all. So, if we do WFCORE-2858 we could:
> a) Accept this, and let the op roll out. That should be an RFE though, with analysis that rolling it out would be harmless.
> b) Remove the op from the profile. It never did anything useful (just a no-op that isn't rolled out) so removing it is only
> a semi-breaking change.
> c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
> Choice c) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) and b) still options for the future, so that's what will be done as part of this work.
> 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.
> Nothing will be done on these as part of this work, but a separate issue will be filed.
> 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.
> 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.
> Nothing will be done on these as part of this work, but a separate issue will be filed.
> 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.
> 12) A number of ops are using withFlags(OperationEntry.Flag.RUNTIME_ONLY) instead of setRuntimeOnly(). The effect is the same so this is harmless but a minor useful side task is to switch to setRuntimeOnly(). That will make it easier to find these ops.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months