[
https://issues.apache.org/jira/browse/IGNITE-28837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-28837:
------------------------------------
Description:
Add the ability for internal components (e.g., plugins and SPIs) to provide
their own independent sets of features and versions.
h2. Proposed Design
Introduce the concept of an *Ignite component* participating in Rolling Upgrade.
Each component provides:
* Component name.
* Component version.
* Set of supported {{{}IgniteFeature{}}}s.
Component registration should be performed through the existing *Extensions*
mechanism.
Each participating component implements the following internal interface:
{code:java}
public interface IgniteComponentFeaturesProvider extends Extension {
/** Component name. */
String componentName();
/** Component version. */
IgniteProductVersion componentVersion();
/** Features supported by the component. */
Collection<IgniteFeature> features();
}
{code}
The implementation is registered in the {{ExtensionRegistry}} during plugin
initialization:
{code:java}
@Override public void initExtensions(PluginContext ctx, ExtensionRegistry
registry) {
registry.registerExtension(
IgniteComponentFeaturesProvider.class,
new TestPluginComponentFeaturesProvider(versions.pluginVersion()));
}
{code}
Initially, feature state queries and feature activation notifications will only
be available through {{{}GridKernalContext{}}}, as this API is intended for
internal use.
h2. Validation Rules
The presence of registered components should be validated during node join.
h3. Server nodes
When Rolling Upgrade is *not* active:
* All server nodes must expose the same set of registered components.
h3. Client nodes
* Every component present on a client node must also be present on the server
nodes.
* Client nodes are allowed to omit components that exist on the server.
This relaxation is intentional because:
* Plugins may not be required on client nodes.
* Client node configurations are often outside the control of the cluster
administrator.
was:Add the ability for internal components (e.g., plugins and SPIs) to
provide their own independent sets of features and versions.
> Add support for multiple independent feature sets during RU
> -----------------------------------------------------------
>
> Key: IGNITE-28837
> URL: https://issues.apache.org/jira/browse/IGNITE-28837
> Project: Ignite
> Issue Type: Task
> Reporter: Mikhail Petrov
> Assignee: Mikhail Petrov
> Priority: Major
> Labels: IEP-132, ise
> Fix For: 2.19
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Add the ability for internal components (e.g., plugins and SPIs) to provide
> their own independent sets of features and versions.
> h2. Proposed Design
> Introduce the concept of an *Ignite component* participating in Rolling
> Upgrade.
> Each component provides:
> * Component name.
> * Component version.
> * Set of supported {{{}IgniteFeature{}}}s.
> Component registration should be performed through the existing *Extensions*
> mechanism.
> Each participating component implements the following internal interface:
>
> {code:java}
> public interface IgniteComponentFeaturesProvider extends Extension {
> /** Component name. */
> String componentName();
> /** Component version. */
> IgniteProductVersion componentVersion();
> /** Features supported by the component. */
> Collection<IgniteFeature> features();
> }
> {code}
> The implementation is registered in the {{ExtensionRegistry}} during plugin
> initialization:
>
> {code:java}
> @Override public void initExtensions(PluginContext ctx, ExtensionRegistry
> registry) {
> registry.registerExtension(
> IgniteComponentFeaturesProvider.class,
> new TestPluginComponentFeaturesProvider(versions.pluginVersion()));
> }
> {code}
> Initially, feature state queries and feature activation notifications will
> only be available through {{{}GridKernalContext{}}}, as this API is intended
> for internal use.
> h2. Validation Rules
> The presence of registered components should be validated during node join.
> h3. Server nodes
> When Rolling Upgrade is *not* active:
> * All server nodes must expose the same set of registered components.
> h3. Client nodes
> * Every component present on a client node must also be present on the
> server nodes.
> * Client nodes are allowed to omit components that exist on the server.
> This relaxation is intentional because:
> * Plugins may not be required on client nodes.
> * Client node configurations are often outside the control of the cluster
> administrator.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
