Skip to content
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

Fix AddUpdateAPIService for openapiv2 #120814

Merged

Conversation

Jefftree
Copy link
Member

@Jefftree Jefftree commented Sep 21, 2023

What type of PR is this?

/kind bug
/kind regression

What this PR does / why we need it:

A couple of issues were discovered and they've been combined into this PR since they all need a backport.

For #120758: Triggered by a race when a GET to /openapi/v2 is called between https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kube-aggregator/pkg/controllers/openapi/aggregator/aggregator.go#L227 and https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kube-aggregator/pkg/controllers/openapi/aggregator/aggregator.go#L230

Fix is to initialize the cache with empty data so aggregation won't have problems.

For #120739: AddUpdateAPIService was adding and also updating the apiservice spec. The apiservice spec update should be done async by the controller.

Fix is to not update the spec in the addupdateapiservice flow during startup. This is handled async by the openapi controller.

I've discovered #120878 while working on the above two issues: The code path when an apiservice exists and needs to be updated was not handled properly. I've refactored the CacheableDownloader to have an new function UpdateHandler() and call that in AddUpdateAPIService() if the apiservice already exists. I've also removed the decorateError function and integrated the better logging directly in the downloader.

I've fixed the AddUpdateAPIService flow and added integration tests to simulate the cases described in #120758 and #120739. Added additional unit tests to catch #120878. Tried to keep the changes self contained since we need to backport.

Which issue(s) this PR fixes:

Fixes #120758
Fixes #120739
Fixes #120878

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fix regression with adding aggregated apiservices panicking and affected health check introduced in release v1.28.0

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. kind/bug Categorizes issue or PR as related to a bug. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. kind/regression Categorizes issue or PR as related to a regression from a prior release. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels Sep 21, 2023
@k8s-ci-robot k8s-ci-robot added area/test sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/testing Categorizes an issue or PR as relevant to SIG Testing. release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Sep 21, 2023
@jiahuif
Copy link
Member

jiahuif commented Sep 21, 2023

/assign @apelisse

@jiahuif
Copy link
Member

jiahuif commented Sep 21, 2023

/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Sep 21, 2023
@Jefftree Jefftree force-pushed the fix-openapiv2-aggregator-apiservice branch 6 times, most recently from 70c2e14 to eb867b9 Compare September 21, 2023 19:11
@dims
Copy link
Member

dims commented Sep 22, 2023

@Jefftree will use this PR to try some CI jobs. hope that's ok :)

@dims
Copy link
Member

dims commented Sep 22, 2023

/test pull-kubernetes-e2e-containerd-gce
/test pull-kubernetes-node-e2e-containerd

@liggitt
Copy link
Member

liggitt commented Sep 23, 2023

Please add the exact patch version where the regression was introduced into the release note

d.mutex.Lock()
defer d.mutex.Unlock()
d.handler = handler
}

func (d *cacheableDownloader) Get() (*spec.Swagger, string, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Get is long-running, right? the mutex addition makes that block UpdateHandler, which now blocks specAggregator#AddUpdateAPIService

That means a hang fetching one service's openapi can block processing of other services, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm that's true. What if we have the mutex only be required when we fetch the handler instead of the entire get operation?

Copy link
Member

@liggitt liggitt Oct 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the only thing we need to guard the handler, or is the etag / spec also concurrently modifiable? (can Get be called from multiple threads?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We currently don't call Get() from multiple threads but the defacto cached.Value interface that we follow is supposed to be thread safe (https://github.com/kubernetes/kube-openapi/blob/master/pkg/cached/cache.go#L17-L22).

@apelisse I think this ties into what you mentioned earlier that since we don't evaluate aggregated apiservices lazily, maybe we shouldn't follow cached library interface?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leaving this open before merge just to get @apelisse's feedback

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you don't then you'll have to deal with the etag manually, I'm not sure it would better.

@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 4, 2023
@@ -218,16 +219,21 @@ func (s *specAggregator) AddUpdateAPIService(apiService *v1.APIService, handler
s.mutex.Lock()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if an API Service changes from remote to local (service != nil → service == nil), will the short-circuit return above prevent cleanup from happening? should we call RemoveAPIService in that case?

just noticed this, it's pre-existing in 1.27, so probably best to handle separately in a follow up

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack, will do that in a follow up

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, link the issue here when you open it to close the loop

@Jefftree
Copy link
Member Author

Jefftree commented Oct 4, 2023

/retest

@liggitt
Copy link
Member

liggitt commented Oct 5, 2023

lgtm but will defer to @apelisse on #120814 (comment) before merge

Copy link
Member

@apelisse apelisse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My comments are nits and don't have to be fixed here since they mostly relate to style and have no behavior impact. LGTM for me, thanks.

return spec, etag, err
}

func (d *cacheableDownloader) getWithHandler(h http.Handler) (*spec.Swagger, string, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a get without handler? The name sounds like there would be. But wait, I think I see where this is coming from. You shouldn't have to receive the handler here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated with the atomic pointer, but kept this function. Separating the two functions lets us decorate the error with the apiservice name. lmk if you have thoughts, thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I still think it's weird to pass to getWithHandler one of it's own member though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just do ...

spec, etag, err := d.get()
...
func (d *cacheableDownloader) get() (*spec.Swagger, string, error) {
    h := *d.handler.Load()
...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

d.mutex.Lock()
defer d.mutex.Unlock()
d.handler = handler
}

func (d *cacheableDownloader) Get() (*spec.Swagger, string, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you don't then you'll have to deal with the etag manually, I'm not sure it would better.

@liggitt
Copy link
Member

liggitt commented Oct 6, 2023

/retest
/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apelisse, Jefftree, liggitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 6, 2023
@liggitt
Copy link
Member

liggitt commented Oct 6, 2023

/hold in case you want to incorporate @apelisse's comments here before backport

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 6, 2023
@Jefftree Jefftree force-pushed the fix-openapiv2-aggregator-apiservice branch from 3e23beb to 14e3a3a Compare October 6, 2023 15:39
@Jefftree Jefftree force-pushed the fix-openapiv2-aggregator-apiservice branch from 14e3a3a to 89adbb4 Compare October 6, 2023 16:58
@apelisse
Copy link
Member

apelisse commented Oct 6, 2023

Thanks
/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 6, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 4720303ed0593197c1a1e5ab658781aacb568cfc

@liggitt
Copy link
Member

liggitt commented Oct 6, 2023

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 6, 2023
@k8s-ci-robot k8s-ci-robot merged commit e339e03 into kubernetes:master Oct 6, 2023
15 checks passed
@k8s-ci-robot k8s-ci-robot added this to the v1.29 milestone Oct 6, 2023
k8s-ci-robot added a commit that referenced this pull request Oct 12, 2023
…0814-upstream-release-1.28

Automated cherry pick of #120814: Fix 120758 - prevent cache Load on uninitialized spec
@Jefftree Jefftree deleted the fix-openapiv2-aggregator-apiservice branch January 25, 2024 22:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/test cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/bug Categorizes issue or PR as related to a bug. kind/regression Categorizes issue or PR as related to a regression from a prior release. lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
6 participants