[
https://issues.apache.org/jira/browse/IGNITE-29256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29256:
--------------------------------------
Description:
On a running node, outgoing communication connections already pick up the
context after {{init()}}. Discovery, incoming communication, the client
connector and binary REST keep the context they obtained at startup. Make new
connections on all four transports use the current context.
h3. What to deliver
# Use the current context of an {{AbstractSslContextFactory}} for each new
discovery and communication connection in both directions, and for new client
connector and binary REST connections. Other factory types retain their
existing behavior.
# Keep established connections open. During a reload and after a failed reload,
new connections use the previous context. Keep server mode, client
authentication, handshake timeouts, protocols, cipher suites and existing
startup checks. A failure setting up TLS on one accepted discovery socket
leaves the listener available.
h3. Compatibility
Keep the protected {{TcpDiscoverySpi.sslSockFactory}} and {{sslSrvSockFactory}}
fields and mark them {{@Deprecated}}. Existing subclasses can still reference
them. Discovery no longer reads them, reload leaves their startup values in
place, and assigning either field in a subclass no longer affects connections.
State these limits in the fields' Javadoc.
h3. Acceptance
Call {{init()}} on a running node from a test and verify key and trust rotation
on new connections across the four transports, including both directions of
discovery and communication. Check that an established connection stays usable
and a new connection still uses the old material during loading and after
failure. Cover a factory shared by multiple transports and confirm that the
discovery listener accepts another connection after a socket setup failure.
Depends on IGNITE-29209. The management command belongs to IGNITE-29210.
Scheduling and HTTP REST are separate.
was:
On a running node, outgoing communication connections already pick up the
context after {{init()}}. Discovery, incoming communication, the client
connector and binary REST keep the context they obtained at startup. Make new
connections on all four transports use the current context.
h3. What to deliver
# Use the current context of an {{AbstractSslContextFactory}} for each new
discovery and communication connection in both directions, and for new client
connector and binary REST connections. Other factory types retain their
existing behavior.
# Keep established connections open. During a reload and after a failed reload,
new connections use the previous context. Keep server mode, client
authentication, handshake timeouts, protocols, cipher suites and existing
startup checks. A failure setting up TLS on one accepted discovery socket
leaves the listener available.
h3. Compatibility
Keep the protected {{TcpDiscoverySpi.sslSockFactory}} and {{sslSrvSockFactory}}
fields and mark them {{@Deprecated}}. They retain the socket factories assigned
at startup, so existing subclasses can still reference them. Discovery no
longer reads them. They keep their startup values after reload, and assigning
either field in a subclass no longer affects connections.
h3. Acceptance
Call {{init()}} on a running node from a test and verify key and trust rotation
on new connections across the four transports, including both directions of
discovery and communication. Check that an established connection stays usable
and a new connection still uses the old material during loading and after
failure. Cover a factory shared by multiple transports and confirm that the
discovery listener accepts another connection after a socket setup failure.
Depends on IGNITE-29209. The management command belongs to IGNITE-29210.
Scheduling and HTTP REST are separate.
> Use the factory's current SSL context for new TCP connections
> -------------------------------------------------------------
>
> Key: IGNITE-29256
> URL: https://issues.apache.org/jira/browse/IGNITE-29256
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
>
> On a running node, outgoing communication connections already pick up the
> context after {{init()}}. Discovery, incoming communication, the client
> connector and binary REST keep the context they obtained at startup. Make new
> connections on all four transports use the current context.
> h3. What to deliver
> # Use the current context of an {{AbstractSslContextFactory}} for each new
> discovery and communication connection in both directions, and for new client
> connector and binary REST connections. Other factory types retain their
> existing behavior.
> # Keep established connections open. During a reload and after a failed
> reload, new connections use the previous context. Keep server mode, client
> authentication, handshake timeouts, protocols, cipher suites and existing
> startup checks. A failure setting up TLS on one accepted discovery socket
> leaves the listener available.
> h3. Compatibility
> Keep the protected {{TcpDiscoverySpi.sslSockFactory}} and
> {{sslSrvSockFactory}} fields and mark them {{@Deprecated}}. Existing
> subclasses can still reference them. Discovery no longer reads them, reload
> leaves their startup values in place, and assigning either field in a
> subclass no longer affects connections. State these limits in the fields'
> Javadoc.
> h3. Acceptance
> Call {{init()}} on a running node from a test and verify key and trust
> rotation on new connections across the four transports, including both
> directions of discovery and communication. Check that an established
> connection stays usable and a new connection still uses the old material
> during loading and after failure. Cover a factory shared by multiple
> transports and confirm that the discovery listener accepts another connection
> after a socket setup failure.
> Depends on IGNITE-29209. The management command belongs to IGNITE-29210.
> Scheduling and HTTP REST are separate.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
