[
https://issues.apache.org/jira/browse/IGNITE-29209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29209:
--------------------------------------
Description:
Let an SSL context factory subclass replace its cached context with one built
from its current settings, keys and trust. IGNITE-29256 and IGNITE-29210 use
this operation to support reload on running nodes.
h3. What to deliver
# Give subclasses an explicit {{init()}} operation. After a successful reload,
the base {{create()}} returns the replacement. If loading fails, throw the
error and keep the previous context. Contexts already returned keep their
settings and material.
# Keep the usual cache behavior of {{create()}}, the existing key and trust
loading hooks, and the protected cache field.
# Tell reviewers in the PR that subclasses with their own no-argument
{{init()}} must rename it.
h3. Acceptance
After the factory has returned a context, verify that a successful reload
replaces it and a failed load preserves it.
Later tickets cover transport changes, running-node commands, certificate dates
and scheduling.
[Implementation and checks in PR
#13751|https://github.com/apache/ignite/pull/13751]
was:
Allow an SSL context factory that has already created a context to reload it
from its current settings, keys and trust material. This is the factory
operation needed by IGNITE-29256 and IGNITE-29210.
h3. What to deliver
# Expose an explicit reload operation to factory subclasses.
# After a successful reload, subsequent {{create()}} calls return the new
context. If loading fails, throw the error and keep the previous context.
Contexts returned earlier do not change.
# Preserve normal cached {{create()}} behavior, existing key/trust loading
hooks and the protected cache field.
# State in the PR that subclasses declaring their own no-argument {{init()}}
must rename it.
h3. Acceptance
Verify successful reload after the factory has been used and preservation of
the previous context after a failed load.
Running-node commands, transport changes, certificate dates and scheduling
belong to later tickets.
[Implementation and checks: PR
#13751|https://github.com/apache/ignite/pull/13751]
> Allow SSL context factories to reload their context
> ---------------------------------------------------
>
> Key: IGNITE-29209
> URL: https://issues.apache.org/jira/browse/IGNITE-29209
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Let an SSL context factory subclass replace its cached context with one built
> from its current settings, keys and trust. IGNITE-29256 and IGNITE-29210 use
> this operation to support reload on running nodes.
> h3. What to deliver
> # Give subclasses an explicit {{init()}} operation. After a successful
> reload, the base {{create()}} returns the replacement. If loading fails,
> throw the error and keep the previous context. Contexts already returned keep
> their settings and material.
> # Keep the usual cache behavior of {{create()}}, the existing key and trust
> loading hooks, and the protected cache field.
> # Tell reviewers in the PR that subclasses with their own no-argument
> {{init()}} must rename it.
> h3. Acceptance
> After the factory has returned a context, verify that a successful reload
> replaces it and a failed load preserves it.
> Later tickets cover transport changes, running-node commands, certificate
> dates and scheduling.
> [Implementation and checks in PR
> #13751|https://github.com/apache/ignite/pull/13751]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
