Because the kubernetes import mod version is 0.8.6 , that had many problems, can tag a new version

[wawa0210]

I found a issue on kubernetes kubernetes/kubernetes#79515

then i found that ,the kubernetes 1.15 import hcsshim version is 0.8.6 four mouth ago tagged

When i import a newest version, everything is ok

So i pull a request to kubernetes , kubernetes/kubernetes#80116 they told me they want to avoid using a random SHA . So can you cut a new version such 0.8.7?

[wawa0210]

@jterry75 @jhowardmsft can you help me
the kubernetes link pr : kubernetes/kubernetes#80116

[jterry75]

@wawa0210 - We are not testing with Kubernetes directly. I am hesitant to make a tagged release that says support here. Can you describe what you are looking for?

[wawa0210]

@jterry75

Since kubernetes refers to this project, go mod refers to v0.0.0-20190110205307-69ac8d3f7fc1 in kubernetes version 1.14.3，every thing is ok , but in kubernetes 1.15, it refers to hcsshim 0.8.6, a long time ago. The tag is earlier than the version referenced by kubernetes 1.14.3. I found a bug in kube-proxy calling hcsshim using kubernetes 1.15. Later I updated the reference hcsshim version to a newer version and found that the bug has been fixed. So I gave kubernetes a pr, referring to the newer version number v0.0.0-20190417211021-672e52e9209d. But they told me that I need to use a tag to regulate the go mod reference.

---

ths iussue is that: kubernetes/kubernetes#79515

the kube-proxy call hcnnetwork.go using networkName: 'crb0' and throw exception 'Network Id not found', but the flannel host-gw is normal

the hcsshim 0.8.6 had this issue but the new version is no problem

So, can you tag a new version 😭 😭 ?

[panpan0000]

Hmm... it looks like a dependency between kubernetes repo and hcsshim repo.
I believe addressing this issue and supporting of latest kubernetes 1.15 will also help more adoption of hcsshim .
Thanks all.

[dims]

@jhowardmsft @jterry75 John, Terry, Can we please have a new release of hcsshim for use in kubernetes?

[TBBle]

Related to #700, which intended to document that tagged versions are not for Kubernetes.

[jterry75]

@TBBle - I understand its confusing but the general problem is that tagged releases only go through Docker testing, except for the shim which is built out of our repo and a binary dependency to containerd based on a stable API. We are not doing any vendor based testing for k8s so using that tag doesnt mean much and we don't know for certain we didn't break it. Its really up to k8s to vendor it in as needed and decide if it meets the bar or not which is why we recommended using commit hashes in the first place.

[TBBle]

Thank you, that makes sense. So #700 is still the accurate direction, except that ContainerD is (as of 0.8.7) now working from a stable API (Runtime V2 shim).

Hence it's (I guess?) reasonable for ContainerD to track tags (if they wanted, no indication I saw of a strong pro-tag policy like k8s had expressed), with the knowledge that they can switch to commit-hashes if this ever proves necessary due to bugs or changes in the small code subset they consume via import.

A 30 second poke on Github suggests it's not as small as I would have guessed, so probably no tags for ContainerD either.

In the end the shim executable is the less-stable more-risky part of the ContainerD question, which is actually part of my motivation for #750, to ease access and updates for the containerd shim binary itself, without needing to hunt through AppVeyor artifacts.

And as far as this ticket is concerned, k8s is in the realm of "Vendor a commit hash, and test it hard", which I guess means it can be closed as "nothing to be done".

[wawa0210]

/close