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

update vendor to latest kubernetes 1.14.0 #299

Merged
merged 1 commit into from
May 14, 2019

Conversation

Madhu-1
Copy link
Collaborator

@Madhu-1 Madhu-1 commented Apr 3, 2019

some of the kubernetes independent packages are moved out of the tree to new projects.

Signed-off-by: Madhu Rajanna madhupr007@gmail.com

@humblec
Copy link
Collaborator

humblec commented Apr 3, 2019

@Madhu-1 its good to move to latest so, 1.14. But I feel, till we stabilize master with v1.0.0 spec with the merge, we should wait.

@leseb
Copy link
Member

leseb commented Apr 3, 2019

Should wait for #297

@Madhu-1 Madhu-1 added the DNM DO NOT MERGE label Apr 3, 2019
@Madhu-1
Copy link
Collaborator Author

Madhu-1 commented Apr 3, 2019

added DNM label to avoid accidental merging

@Madhu-1
Copy link
Collaborator Author

Madhu-1 commented Apr 4, 2019

can you send this PR to master branch? from now onwards we will be using master for csiv1.0 development, Thanks

@Madhu-1 Madhu-1 changed the base branch from csi-v1.0 to master April 4, 2019 05:40
@Madhu-1 Madhu-1 removed the DNM DO NOT MERGE label Apr 4, 2019
@Madhu-1
Copy link
Collaborator Author

Madhu-1 commented Apr 4, 2019

rebased with master, PTAL

@Madhu-1
Copy link
Collaborator Author

Madhu-1 commented Apr 5, 2019

@leseb @ShyamsundarR PTAL

@ShyamsundarR
Copy link
Contributor

@Madhu-1 went through understanding the dependency tree and such, being new to go myself, I have a few questions, which may influence the PR or just be educational for me, hence posting them here to begin with.

  • From what I understand tracing one of the dependency that we use (apimachinery) its compatibility statement, states that a version is compatible with exactly that version of kubernetes. Thus, if we move to 1.14 for apimachinery (as done in the change in this PR) what is the guarantee that the built image will work with v1.13 kubernetes?

  • client-go seems to have more relaxed compatibility matrix, but also states that APIs that are removed on the server but still present in the client-go libraries would not function as required. So, how do we ensure we use a set of APIs that are supported and continue to be supported across at least kubernetes versions that we want to support.

  • A broader question, as we are using kubernetes APIs, and the above compatibility constraints apply afaict, does this mean we need to generate images for different kubernetes versions?

@ShyamsundarR
Copy link
Contributor

Discussed the issue in another forum and figured that kubernetes is backward compatible (at least to an extent) and so we should actually be at deps that are 1.13, in an effort to work against v1.13-15.

I would hence suggest that this change NOT be done at the moment, as we would still need to support kubernetes v1.13.

some of the kubernetes independent
packages are moved out of the tree to
new projects.

Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
@humblec
Copy link
Collaborator

humblec commented May 14, 2019

lgtm. thanks !

@mergify mergify bot merged commit f60a07a into ceph:master May 14, 2019
Madhu-1 pushed a commit to Madhu-1/ceph-csi that referenced this pull request Jun 20, 2024
Syncing latest changes from upstream devel for ceph-csi
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants