Skip to content

Commit

Permalink
docs: add DR about dataplane selection improvements (#4149)
Browse files Browse the repository at this point in the history
* docs: add DR about dataplane selection improvements

* PR remarks
  • Loading branch information
ndr-brt authored May 6, 2024
1 parent 7fbf103 commit 3494af9
Show file tree
Hide file tree
Showing 2 changed files with 43 additions and 2 deletions.
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)

0 comments on commit 3494af9

Please sign in to comment.