Kops: Guidance: When does kops expect Debian Stretch to be the default?

[zapman449]

Currently, Debian Jessie is the default distribution. I see that Stretch AMIs are now supported, but do not seem to be the default.

What is the estimated timeframe for kops to change the default? 1.9 release? 4.82 release?

(We take the kops provided AMIs, and apply several hardening steps for compliance reasons, and then leverage those modified AMIs. We will need to update that hardening process significantly to accommodate the new distribution)

[chrislovecnm]

This is tied to the new image, which should drop with kops 1.8. Which hopefully before re invent

[justinsb]

So we have a stretch AMI for 1.8 now, in addition to the jessie one. The jessie images with ENA simply weren't booting, and I haven't been able to figure out why. For kops 1.8, jessie will remain the default, and we'll point people that want to use ENA to the stretch image.

I don't know if we will be able to get jessie + ENA working (reasonably sure it's _possible_!).

I don't think there's any pressing reason to move to stretch, other than it means we don't necessarily have to compile our own kernel (because stretch has a 4.9 kernel). It does remain to be seen how the stretch kernel compares to the 4.4 LTS kernel we're using on jessie.

Feedback welcome!

[chrislovecnm]

We should have an alpha stretch ami for 1.8

[justinsb]

So I got jessie + ENA working, but the symlink approach to detecting NVME means that we need stretch for NVME, which means we need stretch for C5 / M5 masters or nodes that use EBS volumes.

We'll likely be able to have a hint for people to guide them away from jessie and to stretch for these instance types (but not in 1.8.0, hopefully in 1.8.1), but my guess is that by kops 1.10 NVME will become widespread enough that it'll be annoying not to have it as the default.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[cdenneen]

still seeing jessie in stable and alpha channels for kops
Think stretch is needed for M5, C5 instances?

[arun-gupta]

This is related to https://github.com/kubernetes/kops/issues/4690

[tuananh]

i got the same issue. instance was created but unable to join the cluster

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[olemarkus]

/remove-lifecycle rotten

[thomaspeitz]

Hey devs,

i still do not see debian stretch stable or alpha in 1.10 (https://github.com/kubernetes/kops/blob/master/channels/alpha) - Which is needed for c5 instance support (nvme root disk is not supported). A lot of companies are already using the stretch image without problems so i could just use it as well but it would be cooler to know, why it is not kops default yet. I would like to invest some time to get this fixed.

https://github.com/kubernetes/kops/blob/master/channels/alpha - In the alpha/stable channel there is a reference to https://github.com/kubernetes/kubernetes/issues/56763 which is already closed.

Open issues where this is a problem / reference:
https://github.com/kubernetes/kops/issues/5520
https://github.com/kubernetes/kops/issues/5175
https://github.com/kubernetes/kops/issues/3991
https://github.com/kubernetes/kops/issues/3868

[geojaz]

@tsupertramp I think we're all on the same page here as far as wanting to get stretch as default- sorry that this is confusing and continues to be an issue.

In order to get kops 1.10 out the door (really really late) this week, we decided that jessie was the more conservative and reasonable way to go. The original plan was to go to stretch already, but while preparing the release, there was a testing bug that presented while running stretch, so we went back to jessie. By the time the bug had been sorted, we'd already released a beta version and we decided that it was too big a change to spring on folks at last minute.

We have stretch images prepared already (same name/tag, just change jessie->stretch. I also merged some really basic validation about this issue. And 1.11-alpha will be here very soon and that will default to stretch. That said, our clients have been on the kope.io stretch images for quite awhile with no =

[thomaspeitz]

Thanks @geojaz for your extended answer. This explains a lot and i am very happy to test 1.11-alpha in the future and now feeling more save with 1.10 and stretch images. - Will upgrade all our clusters in the following week :) - Thanks for your time and nice answer. Its great to have you as maintainer!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[bhack]

News?

[Pharb]

@bhack Debian Stretch is the default in Kops 1.11 for Kubernetes 1.11 according to the release notes (#6270). For details see also https://github.com/kubernetes/kops/blob/release-1.11/channels/stable#L26.

[Pharb]

/close

[k8s-ci-robot]

@Pharb: Closing this issue.

In response to this:

/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.