-
Notifications
You must be signed in to change notification settings - Fork 465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WFCORE-6728] Utility to reload servers started by testsuite to a desired stability level #5895
Conversation
} | ||
|
||
// The stability parameter for the reload opration is only registered below the default level | ||
Assume.assumeFalse("Can't reload to a different stability when server stability level is default", currentStability == Stability.DEFAULT && stability != Stability.DEFAULT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should do a read-operation-names and look for the op and Assume.assumeTrue(opnames.contains(theopname)).
IOW don't hard code the current rules about the availability of the op into this test fixture.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need https://issues.redhat.com/browse/WFCORE-6731 and then this can do an Assume.assumeTrue(supported.contains(stability))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bstansberry I'm not totally sure about WFCORE_6731 for this? I am able to start WildFly Core with --stability=default
so I presume that means default is a legal stability level. Still, I can add a placeholder for this check, since there may well be something which isn't turned on in my version of WildFly yet enforcing this.
EDIT: I've looked in ProductConfig and it makes sense now, I can see it :-)
The issue I am trying to solve here, is that if we were to reload to default to run the test, we would not be able to reload back to community since the new reload operation is only registered at that level.
I think I will check the stability of the reload-enhanced operation definition, and check that it would still be available if the reload to the intended stability takes place.
@kabir I changed this to a Feature Request. Re "I'm opening this as a draft for now. If it looks good, I'll add something similar for domain mode." -- This comment might be out of date, but if not I suggest not, not for this iteration. The key use case is testing, and for that use case domain mode is a minor consideration. Better IMHO to just do the standalone bit and come back later for more. As long as you can write an analysis with a clear use case and a solution that logically can be carried forward to other use cases without incompatible change, that's a good target. The more you go beyond that the more time will be needed from others and the longer it will take to get in. |
51d6e3a
to
8cbabde
Compare
c4e0661
to
b1438fc
Compare
Core -> Full Integration Build 13615 outcome was UNKNOWN using a merge of b1438fc |
Core -> Full Integration Build 13368 outcome was UNKNOWN using a merge of b1438fc |
Core -> WildFly Preview Integration Build 13425 outcome was UNKNOWN using a merge of b1438fc |
Core -> Full Integration Build 13370 outcome was FAILURE using a merge of b1438fc |
Core -> WildFly Preview Integration Build 13427 outcome was FAILURE using a merge of b1438fc |
Core -> Full Integration Build 13616 outcome was FAILURE using a merge of b1438fc |
controller/src/main/java/org/jboss/as/controller/extension/ExtensionRegistry.java
Outdated
Show resolved
Hide resolved
controller/src/main/java/org/jboss/as/controller/extension/ExtensionRegistry.java
Outdated
Show resolved
Hide resolved
controller/src/main/java/org/jboss/as/controller/extension/ExtensionRegistry.java
Show resolved
Hide resolved
b1438fc
to
ed3dc9d
Compare
Core -> Full Integration Build 13617 outcome was FAILURE using a merge of ed3dc9d |
Core -> WildFly Preview Integration Build 13428 outcome was FAILURE using a merge of ed3dc9d |
Core -> Full Integration Build 13371 outcome was FAILURE using a merge of ed3dc9d |
Core -> Full Integration Build 13618 outcome was FAILURE using a merge of ed3dc9d |
...oller/src/main/java/org/jboss/as/controller/access/constraint/SensitivityClassification.java
Outdated
Show resolved
Hide resolved
...ller/src/main/java/org/jboss/as/controller/remote/ModelControllerClientOperationHandler.java
Outdated
Show resolved
Hide resolved
...ller/src/main/java/org/jboss/as/controller/remote/TransactionalProtocolOperationHandler.java
Outdated
Show resolved
Hide resolved
|
||
ServerEnvironment recalculateForReload(RunningModeControl runningModeControl) { | ||
if (runningModeControl.isReloaded()) { | ||
Stability stability = runningModeControl.getReloadedStability() != null ? runningModeControl.getReloadedStability() : productConfig.getDefaultStability(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this default to the current value of ServerEnvironment.getStability()? That way a regular reload would reflect the stability level of a previous enhanced reload.
controller/src/main/java/org/jboss/as/controller/extension/ExtensionRegistry.java
Show resolved
Hide resolved
server/src/main/java/org/jboss/as/server/operations/ServerProcessReloadHandler.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/jboss/as/server/operations/ServerProcessReloadHandler.java
Outdated
Show resolved
Hide resolved
testsuite/shared/src/main/java/org/wildfly/test/snapshot/ServerSnapshot.java
Outdated
Show resolved
Hide resolved
…a new stability level This is not available at all stability levels, and has its own RBAC settings
…Task.setup() method
…f the server config Otherwise, if we were working on a lower stability level, and made changes to the model, those could be stored with s schema from a lower stability level, meaning the reload back to the default community level will fail since it will contain xml elements from a namespace we can't handle
7817dd6
to
2363b2e
Compare
controller/src/main/java/org/jboss/as/controller/RunningModeControl.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/jboss/as/server/ServerEnvironment.java
Outdated
Show resolved
Hide resolved
...ller/src/main/java/org/jboss/as/controller/remote/ModelControllerClientOperationHandler.java
Show resolved
Hide resolved
server/src/main/java/org/jboss/as/server/ServerEnvironment.java
Outdated
Show resolved
Hide resolved
Just a general comment about the |
…uration instances
private Set<Stability> getSupportedStabilityLevels() { | ||
// TODO WFCORE-6731 - see https://github.com/wildfly/wildfly-core/pull/5895#discussion_r1520489808 | ||
// This information will be available in a management operation, For now just return a hardcoded set | ||
return EnumSet.allOf(Stability.class); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://issues.redhat.com/browse/WFCORE-6728
Proposal: wildfly/wildfly-proposals#557