[release/0.8] Revert containerd dep to 1.4.9

[dcantah]

Due to some unfortunate deps in the root go.mod in containerd + some k8s staging
directory behavior, containerd 1.5 errors out when trying to get vendored into
kubernetes/kubernetes. Because we depend on ctrd 1.5, if hcsshim tries to
get bumped it will ask that we also bump their dep of containerd to 1.5
and things will fail also. This reverts our containerd dep for the release/0.8
branch to 1.4 so we're able to circumvent this, at least temporarily.

Issue tracking this problem that contains k8s proposed solution and statements on
this: kubernetes/kubernetes#104827

"Components that have a transitive dependency to anything in k8s.io/kubernetes,
including the staging components, can not be added as a dependency. The
detection and prevention of this in the dependency management scripts is
intentional."

While this work is temporary just to get k8s a new hcsshim release, longer
term we will need to find a way to trim our containerd dep either here, or
containerd will need to get rid of it's k8s.io/* dependencies in their root go.mod
to remove this circular import issue.

The tests ran to make sure nothing broke with this

-All of the tests that currently get ran on a K8s pull request which includes
the AKS engine e2e containerd test suite.
-Containerd integration tests
-Our cri-containerd tests with a shim built from this commit

Signed-off-by: Daniel Canter dcanter@microsoft.com

[kevpar]

It would be helpful to link any issues tracking the overall fix for this problem, as well as any test pass results for the testing you did on this.

[dcantah]

Don't have any tests to link as I ran them locally. Let me see if the e2e tests that Mark had ran have a link or log file. I can add some issues though, not sure if there's one central "Fixing X". They're kind of scattered around on others discovering the same problem

[kevpar]

We think this is something that needs to be resolved centrally in kubernetes, right? So we should try to make sure there is a single primary tracking issue from that perspective.

[dcantah]

I've made an issue on our end to look into getting rid of the ctrd dep in our root go.mod, but yes. We were going to reach out to some folks to inquire on this. Want some people more familiar with the background of why the staging directory is the way it is to open an issue, incase this is just par for the course ( I hope not..). Will do on Tuesday.

[dcantah]

@kevpar Anything else needed to get this in? The advice we've been given is just to trim deps in projects that need to get vendored into k8s/k8s by the way :/ #1148 (comment)

[kevpar]

@kevpar Anything else needed to get this in? The advice we've been given is just to trim deps in projects that need to get vendored into k8s/k8s by the way :/ #1148 (comment)

I'd like to have the commit message updated with the issue link and latest context/plan (k8s does not allow circular dependencies, so this is a temporary fix, and long term we need to remove the dependency loop in some way).

[dcantah]

@kevpar Sure, will update. Gonna do another pseudo-vendor run again to make sure nothing changed in the last week in k8s also.

[dcantah]

@kevpar Updated the commit message, ptal (also force pushed as there was no new changes obviously, just the commit msg)

[dcantah]

kubernetes/kubernetes#104880 Running the k8s test that get run on a pr right now (just the windows/linux containerd tests left) against a branch I made on here with this work.

[kevpar]

Only other thing that would be nice to see is a description of what testing was done (so we can review if this breaks something down the line). Otherwise LGTM.

[dcantah]

Only other thing that would be nice to see is a description of what testing was done (so we can review if this breaks something down the line). Otherwise LGTM.

Ok, I will add to the commit desc. All the k8s tests just came back green. Gonna run our cri-containerd tests one more time with a shim built from this branch

[dcantah]

Our integration tests came back alright (minus the tests that I can't actually run on my machine e.g. the device ones). Going to check this in.

[thaJeztah]

Perhaps on the hcsshim side, it would make sense to make cmd/ (or each binary under cmd/) separate go modules. That way the "library code" provided by hcshhim, and "binary code" would be separated.

I was working on something similar for https://github.com/containerd/imgcrypt - containerd/imgcrypt#50 (haven't found time to continue that work yet)