vendor: bump gopkg.in/yaml.v2 v2.2.8

[thaJeztah]

full diff: go-yaml/yaml@v2.2.4...v2.2.8

includes:

• go-yaml/yaml@f90ceb4 Fix check for non-map alias merging in v2
  • fix for "yaml.Unmarshal crashes on "assignment to entry in nil map""
• go-yaml/yaml 543 Port stale simple_keys fix to v2
• go-yaml/yaml@1f64d61 Fix issue in simple_keys improvements
  • fixes "Invalid simple_keys now cause panics later in decode"
• go-yaml/yaml 555 Optimize cases with long potential simple_keys

[k8s-ci-robot]

Hi @thaJeztah. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[thaJeztah]

opening for consideration; note that Kubernetes 1.17.1 does not yet use this version, so I wasn't sure if this project wants to stick to the exact version used in Kubernetes, or if being "ahead" is ok

[mikebrow]

opening for consideration; note that Kubernetes 1.17.1 does not yet use this version, so I wasn't sure if this project wants to stick to the exact version used in Kubernetes, or if being "ahead" is ok

Being slightly ahead of k8s is ok for short stretches so long as it's for a sound reason and we are not breaking compatibility with the supported k8s releases. I don't see us using yaml parsing for any of the CRI interfaces.(added note: unless it's hidden in grpc) We do use yaml for some install / ansible code, but that should be ok and we would not yet be using the new fields offered by this update. So.. let's test this out.

[mikebrow]

/ok-to-test

[mikebrow]

LGTM

[dims]

LGTM

[mikebrow]

@thaJeztah Thanks a ton.. I think just need this yaml bump cherry picked to 1.3? need a spread sheet :)

[thaJeztah]

Yes, we should cherry-pick this one, and possibly update kubernetes to the latest 1.16.x version (see #1386 (comment))

[mikebrow]

"possibly" Yes, as you properly surmised this would be a big change for what is now a fairly old (in k8s terms) service branch. Notably Kube release support is only n-2 (plus CVE special cases) and they bump every quarter, making the release march with new features and deprecations only 9months long. If there are breaking changes in k8s due to deprecations, api additions, or just accidents we may be forcing 1.2 users of containerd to bump up their k8s. Gulp. You'll also note we have differences in CI testing as well between 1.2 and 1.3 and master, meaning some breaks might not get tested unless that is also merge where intertwined with the 1.3 release. Further, if cloud users don't bump k8s or do but don't go from 1.12 to 1.16 the mix of 1.13,14,15 releases on 1.2 code base... It might make more sense to ask k8s for 1.12 or 1.14 cve prs, than to bump our maintenance release (1.2) up. I'll be pinging sig-node folks on this.

[thaJeztah]

oh, sorry meant the 1.3 branch, which is already on kubernetes 1.16, but currently on 1.16.3 (which is not the latest patch release of 1.16);

cri/vendor.conf

Lines 57 to 61 in b350e25

	k8s.io/cri-api kubernetes-1.16.3
	k8s.io/client-go kubernetes-1.16.3
	k8s.io/api kubernetes-1.16.3
	k8s.io/apiserver kubernetes-1.16.3
	k8s.io/apimachinery kubernetes-1.16.3

[mikebrow]

whew thx