Sig-release: 1.18.0-alpha.1 tag cutting request.

[bg-chun]

The CRI-API got new fields to support hugepages at the container level.
(Before of this, we set hugepages limit on pod level cgroup, even though hugepages are container level resources)
This change makes container runtimes to be able to set hugepages limit on container level cgroup sandbox, we call it as container isolation of hugepages.
To make it, container runtimes(Docker, Containerd, cri-o) should to be updated.
It means that the vendors of container runtimes have to be updated to point new CRI-API commit point, which includes new fields.

The reason why I ask cutting 1.18.0-alpha.1 tag earlier than the regular process.

• I don't think it makes sense that updating CRI-API vendor of container runtimes to point commit on the master branch, at least it should be an alpha or beta release tag.
• Due to the complexity of vendors, we have update vendors more than twice. it means this work will take long time, but we have to finish this work before 1.18 code freeze(we don't know the date yet)
  For an example of docker, we have to 1)update vendor of docker to 2)update docker side , then we have to 3)update Kubernetes vendor to 4)update dockershim.

Here are relevant links.
KEP: https://github.com/kubernetes/enhancements/pull/1199
Merged PR on Kubernetes repo: https://github.com/kubernetes/kubernetes/pull/83614
Cherry-picked commit on CRI-API repo: https://github.com/kubernetes/cri-api/commit/75b5acf9ef337c48e074816b586a9eeb2ee6f2f7

[justaugustus]

/assign
/sig release
/area release-eng
/milestone v1.18
/priority important-soon
/kind feature

[saschagrunert]

Hm, I'm thinking if we should change that in general than just for this exception. :thinking:

From a container runtime perspective (speaking only of CRI-O) I see no big problem in vendoring a kubernetes master commit on the master branch of CRI-O, if the conformance tests are succeeding.

[justaugustus]

As a point, for people who might check this issue out later...
We do _NOT_ make it a habit of arbitrarily cutting releases by request.

_However_, v1.18.0-alpha.0 was cut on 10/29 and it is 1892 commits behind master.
I don't feel that using that tag would give an accurate representation of what's on master today.

From @liggitt in #sig-release:

At one point, we cut .alpha.1 releases immediately after .0 releases
It's difficult for the latest tagged 1.18.x dev release to be missing significant amounts of 1.17 content

Given that we've just finished a shorter release cycle and v1.18.0-alpha.1 wouldn't have happened until about two weeks into the new cycle, we would've had about a two and a half month gap between 1.18 tags.

Jordan mentioned that we used to cut an x.y+1.alpha.1 immediately after the x.y.0 releases and I think that's a reasonable expectation, so I'd like to add that as a post-release task in the Branch Manager handbook. @idealhack also +1'ed moving forward with this in the channel.

I've added that as an action item in the release cut issue for v1.18.0-alpha.1.

@alejandrox1 @kubernetes/release-engineering
(for visibility)

[tpepper]

I agree that a next alpha should be cut when the prior 1.Y.0 release is cut, and in the meantime doing a next 1.18.0-alpha makes sense.

(It would be nice to have these _NOT_ explicitly declared numerically versus the calendar or other actions, aside from 'alpha.0' happening at new release branch creation, and instead a tool step that is "build next alpha" were a thing, and at key points we run that.)

[justaugustus]

@tpepper -- Agreed. Let's discuss more in the new year! :)

To close the loop on this:

• Kubernetes v1.18.0-alpha.1 has been released: https://github.com/kubernetes/kubernetes/releases/tag/v1.18.0-alpha.1
• CRI-API has been released (with two tags):
  
  
  
  • https://github.com/kubernetes/cri-api/releases/tag/kubernetes-1.18.0-alpha.1
  
  
  • https://github.com/kubernetes/cri-api/releases/tag/v0.18.0-alpha.1
  
  

/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

@tpepper -- Agreed. Let's discuss more in the new year! :)

To close the loop on this:

• Kubernetes v1.18.0-alpha.1 has been released: https://github.com/kubernetes/kubernetes/releases/tag/v1.18.0-alpha.1
• CRI-API has been released (with two tags):
  
  
  
  • https://github.com/kubernetes/cri-api/releases/tag/kubernetes-1.18.0-alpha.1
  
  
  • https://github.com/kubernetes/cri-api/releases/tag/v0.18.0-alpha.1
  
  

/close

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.