allocate external IPs previously used by expunged zones #6483
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
jgallagher
approved these changes
Aug 29, 2024
There was a problem hiding this comment.
Thanks for the more detailed investigation and fix!
having looked through the reconfigurator preparation code it seems like the planning input from the database contains all external IP addresses ever assigned to services.
This is a little surprising to me, but I think in the production path this should work as expected. Planning input is constructed via inspecting the database, and the blueprint executor deletes external IP records for expunged zones. I would not be surprised if many tests don't bother to do the DB cleanup we do in reality.
|
Ah, I didn't notice that we were deleting external IP records. But yes, this should work in production regardless. The number of tests that were impacted by doing it the "right" way were pretty small, so I might look into fixing them instead of this approach. |
jgallagher
approved these changes
Aug 30, 2024
hawkw
pushed a commit
that referenced
this pull request
Aug 31, 2024
Closes #6260. The test I've written successfully fails when the change to `BuilderExternalNetworking::new` is backed out.
jgallagher
added a commit
that referenced
this pull request
Sep 18, 2024
The "Check the planning input" block of code needs to consider _all_ zones in the parent blueprint, including expunged zones. #6483 fixed the planner's ability to reuse external IPs from expunged zones, but accidentally made these checks incorrect, because it's certainly valid for the planning input to still have records for expunged zones. See #6581 (comment) for more context. We also get to remove the somewhat-awkward update_network_resources_from_blueprint() test helper that was needed in #6483 to make some tests pass (because we didn't realize the checks being performed here were wrong).
jgallagher
added a commit
that referenced
this pull request
Sep 18, 2024
The "Check the planning input" block of code needs to consider _all_ zones in the parent blueprint, including expunged zones. #6483 fixed the planner's ability to reuse external IPs from expunged zones, but accidentally made these checks incorrect, because it's certainly valid for the planning input to still have records for expunged zones. See #6581 (comment) for more context. We also get to remove the somewhat-awkward update_network_resources_from_blueprint() test helper that was needed in #6483 to make some tests pass (because we didn't realize the checks being performed here were wrong).
jgallagher
added a commit
that referenced
this pull request
Sep 18, 2024
…ng (#6599) The "Check the planning input" block of code needs to consider _all_ zones in the parent blueprint, including expunged zones. #6483 fixed the planner's ability to reuse external IPs from expunged zones, but accidentally made these checks incorrect, because it's certainly valid for the planning input to still have records for expunged zones. See #6581 (comment) for more context. We also get to remove the somewhat-awkward `update_network_resources_from_blueprint()` test helper that was needed to make some tests pass (because we didn't realize the checks being performed here were wrong).
jgallagher
added a commit
that referenced
this pull request
Oct 2, 2024
…rds (#6742) Recapping from the update sync: * #6483 moved the code restored by this PR into a helper method (`update_network_resources_from_blueprint()`), and also added calls to that method to a handful of tests to make them pass * In the external DNS work, we discovered that those tests should not have needed that, and the reason they did was because of a different bug * #6599 fixed that bug and removed `update_network_resources_from_blueprint()` and all its callers, but neglected to restore this code, meaning the `PlanningInput`s our tests create from their initial system descriptions never had any external networking records
hawkw
pushed a commit
that referenced
this pull request
Oct 2, 2024
…rds (#6742) Recapping from the update sync: * #6483 moved the code restored by this PR into a helper method (`update_network_resources_from_blueprint()`), and also added calls to that method to a handful of tests to make them pass * In the external DNS work, we discovered that those tests should not have needed that, and the reason they did was because of a different bug * #6599 fixed that bug and removed `update_network_resources_from_blueprint()` and all its callers, but neglected to restore this code, meaning the `PlanningInput`s our tests create from their initial system descriptions never had any external networking records
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.
Closes #6260.
When applying the change suggested in that issue, some tests fail because the IPs in the planning input are no longer considered "seen". This might be due to tests not cleaning up the planning input between changes, but having looked through the reconfigurator preparation code it seems like the planning input from the database contains all external IP addresses ever assigned to services.The test I've written successfully fails when the change to
BuilderExternalNetworking::newis backed out.