Add stricter types to some of the fields in the database status. #2272
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Result of fdb-kubernetes-operator-pr on Linux RHEL 9
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Please include a summary of the change and which issue is addressed. If this change resolves an issue, please include the issue number in the description.
When looking at how we were using the database status in some other projects, I noticed frequent type conversions in a couple of places. This updates the related fields to have more precise types, reflecting the ranges of values they can hold.
Type of change
Please select one of the options below.
Discussion
Are there any design details that you would like to discuss further?
I'm keeping this as a draft PR to start with, because I realized it presented a small breaking change, and I wanted to get some feedback on how we want to handle that in general. Is it better to leave this kind of change to a major version, and maybe add TODOs to indicate that we should follow up on these changes in the next major release?
Testing
Please describe the tests that you ran to verify your changes. Unit tests?
Manual testing?
I updated the types in the unit tests, and ran the test suite locally.
Do we need to perform additional testing once this is merged, or perform in a larger testing environment?
No.
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?
No.
If this change is adding or removing subreconcilers, have we updated the core technical design doc to reflect that?
No.
If this change is adding new safety checks or new potential failure modes, have we documented and how to debug potential issues?
No.
Follow-up
Are there any follow-up issues that we should pursue in the future?
No.
Does this introduce new defaults that we should re-evaluate in the future?
No.