[COMMUNITY]  Ability to reload a Host Controller to a different stability level

In  core management

Overview

WFCORE-6728 introduces the ability to reload a standalone server to a different stability level. This is mainly for the testsuite to be able to reload the server to a different stability level before running the tests, and to reload back to the original stability level after the tests have completed.

This proposal is to extend this functionality to domain mode and provide a method to reload a Host Controller to a different stability level for testing purposes.

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 controller, host-controller and testsuite/shared modules.

Other Interested Projects

Relevant Installation Types

  • Traditional standalone server (unzipped or provisioned by Galleon)

  • Managed domain

  • OpenShift s2i

  • Bootable jar

Requirements

Hard Requirements

  • There will be a new operation based on the current reload operation introduced for host controllers.

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

  • The operation is based on the reload operation as follows:

    • It will add a parameter called stability. This parameter takes the stability level we want to reload the server to.

    • It will remove the restart-servers parameter, as it is not useful in the context of reloading a host to a different stability level. For the reload-enhanced operation, the managed servers will always be restarted to ensure that the managed servers are running with the same stability level as the host controller.

  • 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 classes for the WildFly Core testsuite will be introduced. These use the above operation to reload the DomainTestSupport to the desired stability level before running the tests, and to reload it back to the original stability level after the tests have completed.

  • The DomainTestSupport is always configured with at least one Domain Controller, and optionally it could also contain the configuration for an additional Host controller as a secondary host, and the new utility classes will take this into account.

    • These new classes 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 domain.

      • The enhanced reload operation exists at our current stability level for the host controllers in the domain.

      • It is assumed that if we reload to a higher stability level than the one at which the enhanced reload operation is registered, it is not possible to reload back to the original stability. For example, with the operation currently registered at 'community' level, once reloaded to default stability level, it won’t be possible to reload back to 'community' level because the reload-enhanced operation will not be available.

Nice-to-Have Requirements

Non-Requirements

Future Work

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 parameter, 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/domain module to ensure that the new classes 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