[COMMUNITY]  Ability to reload a server to a different stability level

In  core management

Overview

WildFly’s (and WildFly Core’s) testsuite runs at a particular stability level by default. At the time of writing this is set to the 'community' level.

Since features may be introduced to WildFly at a lower stability level than this (e.g. 'experimental' and 'preview'), those features will not be available at the stability level the tests are currently run. Thus, we need a way to run tests at a chosen stability level.

This proposal attempts to solve that by providing a set of ServerSetupTasks that will reload the server to the desired stability level before running the test. To support this a new management operation based on the existing reload operation will be introduced.

Issue Metadata

Issue

Stability Level

  • Experimental

  • Preview

  • Community

  • default

Dev Contacts

QE Contacts

Testing By

  • Engineering

  • QE

Affected Projects or Components

WildFly Core. The main changes will be in the server, testsuite/shared and testsuite/testsuite-runner modules.

Other Interested Projects

Relevant Installation Types

  • Traditional standalone server (unzipped or provisioned by Galleon)

  • [] Managed domain

  • OpenShift s2i

  • Bootable jar

Requirements

Hard Requirements

  • The WildFly Core test runner is enhanced to handle JUnit Assume.assumeXXX() calls from ServerSetupTasks the same way as in normal test code. Prior to this RFE the resulting AssumptionViolatedException would result in a stacktrace and test error, rather than the test being marked as skipped.

  • There will be a new operation based on the current reload operation introduced for standalone servers.

    • The operation will be registered at stability level 'community' at present

    • The operation is based on the reload operation, and adds a parameter called stability. This parameter takes the stability level we want to reload the server to

    • The operation also supports all the parameters supported by the standard reload operation

    • The operation has its own sensitive target access constraint setting to narrow down who can call it. It is called reload-enhanced and is set to false for accessDefault, readDefault and writeDefault.

  • A set of ServerSetupTasks for the WildFly Core test runner will be introduced. These use the above operation to reload the server to the desired stability level before running the tests, and to reload the server back to the original stability level after the tests have completed.

    • The ServerSetupTasks perform the following checks, and skip the test using JUnit Assume.assumeXXX() if the condition is not met:

      • The desired stability level is one of the ones supported by the server

      • The enhanced reload operation exists at our current stability level

      • We don’t reload the server to a higher stability level than the one at which the enhanced reload operation is registered. This is because we need to reload back to the original stability level after the test has completed, and need the operation to be available. So with the operation currently registered at 'community' level, we cannot reload to default.

Nice-to-Have Requirements

Non-Requirements

Future Work

This is currently only implemented for standalone servers, so there is no domain mode support. In the future it could be nice to be able to reload the host controllers to a different stability level.

Also, as this is currently mainly for the testsuite to be able to reload, there is no special support in the CLI’s reload command for the enhanced reload operation. If this is seen usable for wider use, adding handling to the CLI command to expose the stability parameter could be interesting. The CLI command would need to take into account both the stability level of the server and the user’s RBAC role in order to determine whether the enhanced reload operation is visible to the user. If the operation is visible, and the user wants to use the stability paramter, the enhanced reload operation will be called instead of the current reload operation.

Backwards Compatibility

No, we are adding a new operation, which is mainly for testing as described above. There are no configuration changes.

Default Configuration

No impact

Importing Existing Configuration

No impact

Deployments

No impact

Interoperability

No impact

Security Considerations

RBAC constraints will be configured on the enhanced reload operation to narrow down who can call it.

Test Plan

Tests will be added to the testsuite/standalone module to ensure that the ServerSetupTasks mentioned in the requirements section reload properly to the desired stability levels.

Community Documentation

The only user facing functionality here is the reload-enhanced operation. We deliberately don’t promote direct use of low level reload operations, as any use of those operations requires the caller to properly handle reconnecting to the reloaded server. Our end-user documentation around reloading should focus on the high level CLI reload command, which is out of scope for this proposal.

Additionally, reloading to a different stability level requires great care to make sure the server configuration is compatible with the target stability level.

So, beyond the wildscribe management API documentation no community documentation will be added for this.

Release Note Content