Btw just read in the guide lines about squashing and commit message length: https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#squashing

I will squash it into one commit tomorrow.

@KLazarov: you cannot LGTM your own PR.

In response to this:

/lgtm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/lgtm

/LTGM

Done.

/LTGM

ok could you please also remove var rootCert = chain.ChainElements[chain.ChainElements.Count - 1].Certificate; since it is no longer used.

then /LTGM

The issue that I stumbled upon and I'm trying to fix here is if there is a chain that is multiple steps long in a single file provided by the Service Account.

As we are running a managed Kubernetes cluster, we get our Certificates generated by the provider, and in our case there are multiple certificates in the same file, and they describe the full chain. By running chain.Build(cert) it verifies that the cert that it tries to connect with is actually correctly generated from the Chain.

From what I see chain.ChainPolicy.CustomTrustStore.Add(ca) will not work, as it still needs to verify that the certificate, and it's easiest to do that using chain.Build(cert).

I looked into the code and seems your #859 code

chain.ChainPolicy.CustomTrustStore.Add(ca)

makes more sense

here the code is verifying if each ca cert on the cert's chain should that be verifying cert's chain on a trusted ca?

what is your idea?

/remove-lifecycle rotten

Improve error handling in the follow logs example.

Merge pull request #804 from brendandburns/examples

Improve error handling in the follow logs example.

Bump spring-test from 5.3.19 to 5.3.20

Bumps spring-test from 5.3.19 to 5.3.20.

• Release notes
• Commits

updated-dependencies:

• dependency-name: org.springframework:spring-test dependency-type: direct:production update-type: version-update:semver-patch ...

Signed-off-by: dependabot[bot] support@github.com

Merge pull request #2247 from kubernetes-client/dependabot/maven/org.springframework-spring-test-5.3.20

Bump spring-test from 5.3.19 to 5.3.20

Update to version 0.16.4

Fix github action.

Merge pull request #803 from brendandburns/actions

Fix the github action also rev package version to the next version.

Bumps spring-test from 5.3.19 to 5.3.20.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, dependabot[bot]

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

The pull request process is described here

• ~~OWNERS~~ [brendandburns]

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

/lgtm /approve

The EasyCLA has now been accepted.

I have now added the tests for the issue that my code fixes. They are at the bottom of CertificateValidationTests.cs.

I'm still waiting from my company to completly fill out the EasyCLA as we got a bit stuck on it during the weekend.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: harshitasao To complete the pull request process, please assign roycaihw after the PR has been reviewed. You can assign the PR to them by writing /assign @roycaihw in a comment when ready.

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

• kubernetes/base/OWNERS

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

Welcome @harshitasao! It looks like this is your first PR to kubernetes-client/python 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval. You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation. You can also check if kubernetes-client/python has its own contribution guidelines. You may want to refer to our testing guide if you run into trouble with your tests not passing. If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs! Thank you, and welcome to Kubernetes. :smiley:

What type of PR is this?

bug

What this PR does / why we need it:

Used unittest.mock instead of mock

Which issue(s) this PR fixes:

Fixes #1790

Special notes for your reviewer:

None

Does this PR introduce a user-facing change?

None

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

None

Okay, so if I understand correctly the openapi-generator has not been updated to deal with later versions of hoauth2, right? So if we regenerate right now, the result won't build with the recent Stackage resolvers that use those versions. What do you think of me opening a PR to upstream the changes I made here to Kubernetes.Client.Auth.OIDC?

The hoauth2 changes are limited to /kubernetes-client and so has no interaction with openapi-generator, and so those changes can be made directly to this repo.

• /kubernetes is code-generated.
• /kubernetes-client is not code-generated, and can be update directly in this repo.

If we're upstreaming things to openapi-generator, I kind of want to also upstream the CPP for switching between Aeson 1 and 2. It's actually easy to support both, and it seems like the right thing to do since the ecosystem is still transitioning. What do you think?

Yes, we could upstream the CPP for switching between Aeson 1 and 2. It is only a little more work because there are more files in the generator and sample code that would need CPP, but nothing too bad ( https://github.com/OpenAPITools/openapi-generator/pull/12309/files )