On Tue, Oct 23, 2018 at 11:03:39AM -0400, Antoine Beaupré wrote: > TL;DR: Why not just delegate image management to the LTS team once > oldstable because LTS just like we do with security? Zobel also provided > a good template for the images life cycle which could clarify this on > debian-cloud@, which I fully support.
We could certainly delegate. The goal for the future, though, is to have enough automation in place that continuing to support an old release is simply a matter of not turning off its image generation. For technical reasons, jessie is a bit different, but future releases should be simpler. But the question really isn't "how do we keep publishing and supporting jessie?", it's "should we keep publishing and supporting jessie?" To be clear, the ongoing cost to the cloud team of dealing with jessie on AWS (where this issue originally came up) has been exactly zero, afaict. That is, we haven't actually updated anything in >18 months. Users who launch a jessie image there get 8.7, with 106 pending updates. As long as LTS exists and users are happy with it, there's nothing strictly wrong with this situation. They should update their instances and reboot, but from there, they are free to continue using them in relative safety. > But in the cloud infrastructure, things are slightly different. The base > image isn't as important as the application and/or data that runs on > top. In the cloud, we install new "machines" all the time, sometimes as > part of CI/CD processes and those machines are not "pets", they are > "cattle" and recycled constantly. That's a very common use case, for sure, but not the only one we want to support. We definitely do have people who launch an instance and then keep it around for a long time, interacting with and configuring it by hand, just as they would with any physical server. (In fact, I recently noticed a bunch of what appeared to be jessie EC2 instances owned by our QA team; when I asked about them, I learned that they'd all been upgraded in place to stretch.) > In that sense, switching the base OS is, paradoxically, a big deal so > it actually makes sense to install an older release for newer > machines. This is why Travis CI still supports Ubuntu LTS Precise > (12.04) and Trusty (14.04), the former which isn't supported by > Canonical, and it's missing *two* more recent LTS releases, Xenial > (16.04) and Bionic (18.04). Yes, this is correct; it's also something we can continue to support, even without active engagement from the LTS team. As long as the LTS team doesn't do anything that breaks updates on the old images, we're never going to tell people that they can't launch them. The question here was simply about discoverability. If you're a Debian user just beginning exploration of public cloud alternatives, should we make it easy for you to launch LTS instead of stable? > It seems like a nice, symmetrical approach to solve the problem: just > punt this over to the LTS team. We have some capacity and knowledge. I > know I would be happy to work on those images. I'm not even sure that's necessary. I, as a member of the cloud team and maintainer of the stretch AWS images, have already expressed willingness to update the jessie images, if it's something we as a project agree is appropriate. Coming to some clearer agreement about that, especially in light of a decision to the contrary that we made within the cloud team recently, is the sticky point. The perception, afaict, is that LTS only exists because people are paid to work on it. There has not traditionally been sufficient interest within Debian to sustain support of a release for 5 years, so some companies have provided financial incentives. That's fine, but potential somewhat fragile. If that funding goes away, does LTS go away? Is LTS work, for pay, going to drain resources from volunteer work? These questions exist outside the context of the current cloud team issue. The cloud team just happens to be the one to have tripped over them in this instance. noah
signature.asc
Description: PGP signature
