Changing Discovery & PeeringCandidate CRDs behaviour #41
Conversation
This file contains 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
andreacv98
approved these changes
Apr 19, 2024
1.PeeringCandidate CR has no longer Reserved flag 2.Discovery CRD keeps a matching PC list in its status rather than a single PC. 3. Removing PeeringCandidate info from Solver status. 4. The Discovery controller only creates PC for found flavors. It no longers auto-select a PC for reservation. 5. The Discovery controller returns a list of PC in its status, no longer a single (reserved) PC. 5. The Reservation controller first checks if its associated peeringCandidate it is available. If so, it makes it anavailable and goes ahead; otherwise it fails. 6. The association between a Solver and a PC is now available only at the PC CR through spec.solverID; we no longer have any info of the PC inside the Solver CR. Because of this, we no longer have logic handling PC inside the Solver controller. * adjusting CRD creation functions and PC list creation in Discovery controller * bug fix * deleting useless config files * fixing discovery controller misbehaviour * bug fix: adding PC Spec update into reservtion controller * adding creation time info into PC status at creation time * restore default solver sample * bug fix: parse flavour & forgePeeringCandidate cleaning up code second clean up third clean up for merge cleaning up the code removing useless file fix artifacts generation fix comment for linting second fix comment for linting code clean up
This was referenced Apr 22, 2024
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.
Hello everyone.
The aim of this PR is to solve two open issues: #32 and #34.
Shortly, the behavior of some CRDs and controllers was not the one we expected.
More specifically, the Discovery controller was selecting a
PeeringCandidateto "reserve" without giving the user the possibility of manually selecting aPeeringCandidateamong the ones available for aReservation.Additionally, the Discovery controller only returned a single
PeeringCandidatebut we believe a list of possiblePeeringCandidateis more appropriate.Moreover, I found out many redundant relationships among the different objects involved:
SolverCR had a reference to aPeeringCandidateCR in itsstatusand aPeeringCandidateCR had a reference to aSolverCR (through aSolverID) in its ownspecPeeringCandidateCR had a boolean flag reserved in its own spec and a Reservation object had a reference to aPeeringCandidate(through aPeeringCandidateID) in its ownspecThis PR should also cleans up the above circular dependencies.
You can find more info on the commit message body, but please ask me any question you might have.
Waiting for your feedback.
Thanks.
Francesco