Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add DR about dataplane selection improvements #4149

Merged
merged 2 commits into from
May 6, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Dataplane Selection Improvements

## Decision

In the scope of `Dataplane Signaling`, a new way to manage dataplane registration and de-registration will be implemented

## Rationale

Currently, the dataplane registration is done manually by the operator through the management-api, this way is not optimal
because it could lead to errors, plus, there's no way for the control plane to ensure that the dataplane is still active
and ready to accept new transfer requests.

## Approach

The dataplane needs to register itself to the control plane.
To do that, it will need a way to be aware of its supported `source` types and `transferTypes`.

In the first iteration, a new method needs to be added to the `DataSourceFactory` interface, that indicates the type that is handled by the
factory:
```java
public interface DataSourceFactory {
String supportedType();
}
```

Doing so, the `canHandle` method will become obsolete, and the factory will be bound to a specific type.

The `transferTypes` instead will need:
- for `PUSH` flows: the same method will be added to the `DataSinkFactory`, so collecting the types from the registered
factories will give the set of supported `PUSH` types
- for `PULL` flows: the types are registered to the `PublicEndpointGeneratorService`


With this knowledge, the dataplane will be able at startup to register itself to the controlplane via the `control-api`
(and de-register itself at shutdown).

The dataplane will need to have a UUID configured to handle idempotency.

The controlplane will have the possibility to "heartbeat" the dataplane to verify its availability in order to be able
to build the catalog in the correct way and being able to tell if a requested transfer can be started or not.
5 changes: 3 additions & 2 deletions docs/developer/decision-records/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,5 +53,6 @@
- [2023-11-20 Transfer_Type](./2023-11-20-transfer-type)
- [2023-11-09 Protocol Services Refactor](./2023-11-27-refactor-protocol-services)
- [2023-12-12 Data Plane Signaling and Access Control Architecture](./2023-12-12-dataplane-signaling)
- [2023-12-12 Token Handling Refactor](./2023-12-19-token-handling-refactor)
- [2024-01-12 Dynamic_Constraint_Functions](./2024-01-12-dynamic-constraint-functions)
- [2023-12-19 Token Handling Refactor](./2023-12-19-token-handling-refactor)
- [2024-01-12 Dynamic Constraint Functions](./2024-01-12-dynamic-constraint-functions)
- [2024-05-24 Dataplane Selection Improvements](./2024-05-24-dataplane-selection-improvements)
Loading