v1.19.2 💘 Tracking Issue about bottlerocket HOT 9 OPEN

Has there been any thought to any sort of release schedule for BottleRocket? A lot of us run things like Karpenter, which will start rotating nodes very quickly after release. I guess I'm not thinking anything super formal, more just a 'tomorrow at 4pm we plan to release bottle rocket x.yy.zz"

from bottlerocket.

v1.19.2 has selinux permission issue with s3-csi-driver: awslabs/mountpoint-s3-csi-driver#160

from bottlerocket.

This release has been completed on 26th Feb, 2024.

from bottlerocket.

@misterek Bottlerocket's release process is pretty complex, so it's tricky to provide an answer as you suggested, but here goes:

1. there is an approximate 6-8 week cycle for minor releases (x.+.x).
2. Patches/bug fixes (x.x.+) are off cycle and come as soon as possible (and, depending on the severity, it can be accelerated ).
3. The project can't give a deterministic answer of when a release will be available for everyone because:

• for those using in-place, update waves mean that nodes get updates at different times,
• for those using node replacement, updates rely on SSM parameters which hit different regions at different times.

4. On GitHub the last thing that happens is merging the changelog - that's the last signal publicly before starting the release, but it still can take approximately 24-72 hours after that. That delay is unpredictable.

As for timing, most releases tend to complete late in the work day US pacific time.

There are some immovable objects in this process, but glad to hear any feedback on what you'd need.

from bottlerocket.

Thanks for the context @stockholmux !

I perhaps conflated a couple things -- the release and updating the AMI. The AMI update is really the part that I was referring to.

Specifically, where my thinking was is bullet point 3, and in this case, the node replacement. With the last release, nodes were being replaced 5-10 minutes before the GitHub Release was posted. Which, in many respects, was super cool.

I think my dream would be different SSM Parameters that are offset by days, with matching configuration options in Karpenter. i.e. "1 day after release", "5 days after release" "7 days after release". So you could configure dev, qa, and prod to each apply the updates at a differing amount of times after release. To be fair, i think there's only been one release where there's been a problem (1.13), but that'd be a good mix between "update ASAP", and "Allow some soak in time for a release", without having to manage updates manually.

It's a manageable problem as is, but would be even more convenient if we could automate it like that.

from bottlerocket.