This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
Separate filtering into pre- and post- phases #869
Merged
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
squaremo
force-pushed
the
issue/868-cannot-read-cronjob
branch
from
db01dd0
to
4939c7b
Compare
samb1729
reviewed
Dec 28, 2017
release/context.go
Outdated
| // in the slice will have higher priority (they are run first). | ||
| func (rc *ReleaseContext) SelectServices(results update.Result, filters ...update.ControllerFilter) ([]*update.ControllerUpdate, error) { | ||
| defined, err := rc.FindDefinedServices() | ||
| // files and the running platform. `ContollerFilter`s can be provided |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
When selecting controllers to be updated, we find all those defined in the repo, then ask the cluster for each one of those, before subjecting any of them to filtering. In the case of updating a single controller, this means we do a lot of calculation that will be redundant, since we don't care about anything but that controller. It also means any problem with some other controller in the cluster will prevent that controller being updated. Instead, use a prefilter to select only the controllers we're going to ask the cluster about, *then* apply filters on the information we got from the cluster*. An exeption is the treatment of Locked resources -- we have this information from the repo, but look at it _after_ everything else. I've kept this, somewhat artificially, to be consistent for now. *Technically we shouldn't be asking the cluster anything, just updating the controllers defined in the repo. But one thing at a time.
squaremo
force-pushed
the
issue/868-cannot-read-cronjob
branch
from
4939c7b
to
d1ca57f
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
When selecting controllers to be updated, we find all those defined in
the repo, then ask the cluster for each one of those, before
subjecting any of them to filtering.
In the case of updating a single controller, this means we do a lot of
calculation that will be redundant, since we don't care about anything
but that controller. It also means any problem with some other
controller in the cluster will prevent that controller being updated.
Instead, use a prefilter to select only the controllers we're going to
ask the cluster about, then apply filters on the information we got
from the cluster*.
An exeption is the treatment of Locked resources -- we have this
information from the repo, but look at it after everything
else. I've kept this, somewhat artificially, to be consistent for now.
*Technically we shouldn't be asking the cluster anything, just
updating the controllers defined in the repo. But one thing at a time.