-
Notifications
You must be signed in to change notification settings - Fork 84
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
Add Localities to FoundationDBClusterSpec #1353
Add Localities to FoundationDBClusterSpec #1353
Conversation
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the plan to add the functionality in another PR?
I can continue working on this PR no problem. If that is your preference. |
Signed-off-by: Manuel Fontan <[email protected]>
…com/cognitedata/fdb-kubernetes-operator into CDF-1816-Add-fdb-cluster-localities
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Personally I would prefer to implement them in the same PR otherwise we have new fields on the CRD that have no effect. |
Signed-off-by: Manuel Fontan <[email protected]>
Update fdb database configuration to include three data hall redundancy mode Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
…ementation Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
… hall is enabled Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
minor fixes. Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
@johscheuer I have updated the PR with your feedback and added some unit tests (I can add a few more if required). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, I block some time this week to review it.
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Signed-off-by: Manuel Fontan <[email protected]>
Result of fdb-kubernetes-operator-pr on Linux CentOS 7
|
Duplicates #1651 This implementation is for a single FoundationDBCluster but since it has been idle for such a long time and |
Description
This PR implements the first step towards supporting three data hall configuration in the operator.
The current changes will allow to configure three data hall using Localities and Node Selectors.
Since the sidecar currently does not read the topology key label from the pods. We will be providing the NodeSelectors as part of the Locality information. Each node selector must correspond to a data hall.
TopologyKey logic is not implemented in this PR. A validation should report an error if this value is included in the localities spec.
The
data_hall
locality would look something like this:When adding pods the operator will read the FDB status and assign a NS to the pod depending on the process distribution across DH. If there are no processes with DH info it will pick a random NS.
The ProcessGroup Status info will be updated to include the DataHall locality information. This info will be used during pod updates to add the NodeSelector from the Locality in order to calculate the PodSpecHash.
For removals
ChooseDistributedProcesses
has been updated to useFDBLocalityDataHallKey
in the fields in order to maximally pick a well-distributed set of processes.As discussed in:
#348
Type of change
Please select one of the options below.
New feature (non-breaking change which adds functionality)
Discussion
The changes in this PR are based on
https://github.com/FoundationDB/fdb-kubernetes-operator/blob/main/docs/design/three_datahall.md
Testing
Please describe the tests that you ran to verify your changes. Unit tests?
Manual testing?
Do we need to perform additional testing once this is merged, or perform in a larger testing environment?
This changes should not have any effect so additional testing is not required I believe.
Documentation
Did you update relevant documentation within this repository?
No
If this change is adding new functionality, do we need to describe it in our user manual?
Once the three data hall functionality is fully implemented it should be documented indeed.
If this change is adding or removing subreconcilers, have we updated the core technical design doc to reflect that?
N/A
If this change is adding new safety checks or new potential failure modes, have we documented and how to debug potential issues?
N/A
Follow-up
Are there any follow-up issues that we should pursue in the future?
Does this introduce new defaults that we should re-evaluate in the future?
No