bottlerocket
bottlerocket copied to clipboard
bottlerocket-os
v1.19.2 💘 Tracking Issue
This is a "living" issue used to track bug fixes, features, and things landing in the next release of Bottlerocket v1.19.2.
This is a convenient way for the maintainers and the community to have a birds eye view of what's happening in any given Bottlerocket release. You'll find things we're targeting for the release, target dates, and important maintenance tasks.
But anything is subject to change, this isn't a guarantee anything will actually land in a given release, and this tracking issue is not all encompassing. For a full comparison of new things for this release, use the GitHub /compare feature and check the differences between the 1.18.x branch and develop (the latest changes that will eventually land in the 1.19.x branch).
v1.19.1 💘
Release captains 🧑✈️
@vyaghras @rpkelly
Targeting 🎯
- [ ] #3782
- [ ] #3779
- [x] #3718
- [x] #3738
Bug Fixes :lady_beetle:
- [x] #3771
- [x] #3774
Maintenance 🔧
- [x] #3789
- [x] #3767
- [ ] #3775
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"
@misterek Bottlerocket's release process is pretty complex, so it's tricky to provide an answer as you suggested, but here goes:
- there is an approximate 6-8 week cycle for minor releases (x.+.x).
- Patches/bug fixes (x.x.+) are off cycle and come as soon as possible (and, depending on the severity, it can be accelerated ).
- 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.
- 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.
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.
v1.19.2 has selinux permission issue with s3-csi-driver: https://github.com/awslabs/mountpoint-s3-csi-driver/issues/160
@misterek That seems interesting. Do you want to create a separate issue for that so we can track it as a feature request?
@tanvp112 Looks like the CSI driver had a release that rectifies the situation.
@stockholmux -- https://github.com/bottlerocket-os/bottlerocket/issues/3813
Please feel free to read over, adjust, or close if it's not appropriate.
Thanks folks! I'm going to close the issue since we're a couple weeks past the release of 1.19.2