Integration: Expose rest.Config #37
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hoegaarden The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
k8s-ci-robot
added
approved
|
How will a vendoring repo ensure compatibility between the version of apimachinery they are vendoring and the version required by this repo? Will it be necessary to maintain release branches of this repo that track release branches of apimachinery? |
|
@marun: GitHub didn't allow me to assign the following users: marun. Note that only kubernetes-sig-testing members and repo collaborators can be assigned. In response to this:
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. |
|
/assign |
|
@marun: GitHub didn't allow me to assign the following users: marun. Note that only kubernetes-sig-testing members and repo collaborators can be assigned. In response to this:
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. |
I think those questions should be answered by CI. I think we should have this framework tested with multiple versions of If possible, I'd like to avoid release branches. But if that's the way forward we will figure it out. Alternatively, we could not depend on |
|
d5bfdd1 introduces tests against different versions of |
|
My question about 'ensuring compatibility' wasn't related to test compatibility so much as vendoring compatibility. For a repo like As you say, another option is to duplicate code where necessary to minimize vendoring of the staging repos and any others that use release branches. I think the cost of this is likely to be higher than release branches, though, since it will impose both a code maintenance burden and a cognitive burden on developers when discrepancies inevitably arise between the code in this repo and the code it is duplicating from one or more of the staging repos. |
I am not sure if I understand your concerns correctly. Right now the CI tests prove that our framework is compatible with all (tested) versions of client-go. That means that -- as long as this stays true -- anyone that has already vendored any of those versions of As soon as our code is not compatible with a specific version of I feel I am missing your point though ... ? |
|
This PR adds dependencies on |
... and print log versions of some interesting packages.
I thought the tests run against specific versions of Maybe let me explain what I was trying to do:
Now there is a problem with that:
How can I now find out which versions of Version restored by godep: |
|
I'm not sure why the version isn't being set correctly. I'm still not clear on how a repo that is using release branches of staging repos is intended to vendor this repo. Ok, compatibility is being tested. Is it possible to configure dep, run against a repo that is vendoring this one, to ignore the staging repo dependencies defined in Gopkg.toml for this repo (e.g. via overrides in the vendoring repo Gopkg.toml)? |
There was no k8s.io/api in 4.0.0, and no apimachinery in 2.0.0. |
Interesting. |
Probably because you reference them in your code. That's the kind of problems you will see when targetting multiple client-go versions in parallel. This asks for trouble in vendoring and compilation. |
We only reference Anyway, I am looking into how introducing release branches would look like. But I am currently in a big fight with |
|
Ok, we did some experiments on how to potentially vendor this repo (
For 1. we can have tests in CI, and we can document which versions of Regarding 3. we can also document that. But actually the problem arises in the package which vendors this one -- and therefore the documentation about this issue may well be overlooked. So I see two ways how to address that:
Did I miss anything? Any input? Any preference? |
|
@hoegaarden I am not sure why dep+godep is discussed. This is not the problem. There is a general rule: We cannot vendor any packages depending on client-go and friends into Kubernetes. This has nothing to do with the vendoring tool used. It has to do with the conflict of the client-go version in k/k's staging/ and an vendored in test-framework that must be compatible with the published k8s.io/client-go. If we change client-go in k/k, we might have to change the test framework outside of k/k. But the test-framework outside of k/k cannot be changed because then it's incompatible with the published client-go version at k8s.io/client-go. There is no clean process to solve this. Hence, repeating what @marun just wrote, "using client-go in the test-framework" + "using the test-framework inside k/k" unavoidibly means that the test-framework must live inside k/k as a staging/ repo. Btw, better don't make assumptions about the vendoring tool. We might switch to dep at some point kubernetes/kubernetes#57795. |
|
Thanks. I think I am starting to understand all the problems with vendoring a staging repo now. Sorry about the confusion and thanks for the explanations and help. So for now, that means that this cannot be done and I will probably close this PR and the related issue #23. It should be left to the users to create a |
|
I see these options:
|
|
Closing this PR because this implementation would not allow to be vendored into k/k. |
For now, only the
Hostfield is populated. Going forward we can then add all-the-things clients would need to know for connecting to our ControlPlane/APIServer.closes #23