[WFCORE-6731] Expose supported stability levels via the management API #5908
Conversation
github-actions
bot
added
the
deps-ok
| @@ -485,6 +487,7 @@ public HostControllerEnvironment(Map<String, String> hostSystemProperties, boole | |||
| this.processType = processType; | |||
|
|
|||
| this.stability = getEnumProperty(hostSystemProperties, STABILITY, this.productConfig.getDefaultStability()); | |||
| this.stabilities = Collections.unmodifiableSet(productConfig.getStabilitySet()); | |||
There was a problem hiding this comment.
Making this set unmodifiable is the right thing to do, but better to do this directly in ProductConfig: https://github.com/wildfly/wildfly-core/blob/main/version/src/main/java/org/jboss/as/version/ProductConfig.java#L97
That way we prevent anyone from modifying this value, and every process env does not need to perform the same wrapping.
| * @return a set of stability levels | ||
| */ | ||
| public Set<Stability> getStabilities() { | ||
| return this.stabilities; |
There was a problem hiding this comment.
... that way this method (and t can just delegate to ProductConfig.getStabilities().
I would also consider defining this method in ProcessEnvironment to enforce consistency across subclasses.
There was a problem hiding this comment.
I would also consider defining this method in ProcessEnvironment to enforce consistency across subclasses.
@pferraro @yersan This is a good idea but I think it's out of scope for this JIRA. Just because when I look at ProcessEnvironment it's an abstract class (not an interface) shares a lot of functionality with both of its subclasses, but stores and exposes no state itself and thus forces both subclasses to do so. If we're going to change that for this we should revisit all of it, which is out of scope.
I have no idea why it's done this way. My only guess is ProcessEnvironment was originally stateless and over time the two subclasses evolved independently and the kind of refactoring I'm discussing here was never in scope. :)
|
@hpehl Could you please also review, this exposed information will be useful to management clients. |
There was a problem hiding this comment.
In general, LGTM. Thanks @yersan
AIUI, this PR adds two properties to the management model:
- current stability level
- possible stability levels
Some questions:
- Can the user change the stability level at runtime (e.g., using an operation), or is this only possible at startup time when using a command-line option/system property?
- How can I, as a client, detect whether a specific resource, operation, or attribute is only supported for a specific stability level?
|
@hpehl thanks for reviewing it.
There is an ongoing Feature that would allow restarting the server at a different stability level: #5895
When you describe a resource/operation, now the resources provide a field that specifies the higher stability lever where this resource is available. This attribute name is "stability". If the resource / attribute / operation is not suitable to run in the current server stability level, then the resource will not be available. For example, if the operation The operation |
| @@ -304,6 +304,7 @@ public ProcessType getProcessType() { | |||
| private final boolean startGracefully; | |||
| private final GitRepository repository; | |||
| private final Stability stability; | |||
| private final Set<Stability> stabilities; | |||
There was a problem hiding this comment.
This field shouldn't be needed as this.productConfig can be called to get the stabilities set.
| @@ -234,6 +235,7 @@ public class HostControllerEnvironment extends ProcessEnvironment { | |||
|
|
|||
| private final RunningMode initialRunningMode; | |||
| private final Stability stability; | |||
| private final Set<Stability> stabilities; | |||
There was a problem hiding this comment.
This field shouldn't be needed as this.productConfig can be called to get the stabilities set.
|
Superseded by #5917 which resolves the conflict and deals with my minor requests. |
Jira issue: https://issues.redhat.com/browse/WFCORE-6731