[
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 keep their startup
context in discovery and incoming transports; outgoing communication keeps its
existing factory calls.
# 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
For an {{AbstractSslContextFactory}}, Ignite calls {{create()}} for each new
connection, including on NIO threads. Discovery uses the same socket setup path
for all factory types. A custom context must support engine creation for
startup validation, layering TLS over an accepted socket and setting server
mode. Settings applied only by a custom server socket factory no longer affect
discovery connections.
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 context lookup or socket
setup failure. Verify that an ordinary factory can join through the same
discovery path and that a failed context lookup closes only the affected NIO
session.
Depends on IGNITE-29209. The management command belongs to IGNITE-29210.
Scheduling and HTTP REST are separate.
[Implementation plan: PR #13795|https://github.com/apache/ignite/pull/13795]
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}}. 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.
> 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
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 keep their startup
> context in discovery and incoming transports; outgoing communication keeps
> its existing factory calls.
> # 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
> For an {{AbstractSslContextFactory}}, Ignite calls {{create()}} for each new
> connection, including on NIO threads. Discovery uses the same socket setup
> path for all factory types. A custom context must support engine creation for
> startup validation, layering TLS over an accepted socket and setting server
> mode. Settings applied only by a custom server socket factory no longer
> affect discovery connections.
> 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 context lookup or socket setup failure. Verify that an ordinary
> factory can join through the same discovery path and that a failed context
> lookup closes only the affected NIO session.
> Depends on IGNITE-29209. The management command belongs to IGNITE-29210.
> Scheduling and HTTP REST are separate.
> [Implementation plan: PR #13795|https://github.com/apache/ignite/pull/13795]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
