IRT a testing/cutting edge repo, the non-LTS versions of Ceph have been removed because very few people ever used them and tested them. The majority of people that would be using the testing repo would be people needing a bug fix ASAP. Very few people would actually use this regularly and its effectiveness would be almost zero in preventing problems slipping through.

At work I haven't had a problem with which version of Ceph is being installed because we always have local mirrors of the repo that we only update with the upstream repos when we're ready to test a new version in our QA environments long before we promote the version for production use. That said, I've been bit by this multiple times in my home environment where I've accidentally updated a server or reinstalled a server and needed to upgrade my Ceph cluster before I could finish because it installed a newer version of Ceph. I have had to download the entire copy of a version from online, put it into a folder on disk, and set up a repo feeding from that local folder to install a specific version. This would be very handy to just use the ability in apt or yum to just specify a different version of a package in the repo.

Problem releases have become more problematic than needed because the packages were left the default packages after a bug was known because there was no way to remove them from the repo. People continue to see the upgrade and grabbing it not realizing it's a busted release. I've only seen that happen on the ML here, but I personally will not touch a new release for at least 2 weeks after it's been released even in my testing clusters.

On Tue, Sep 24, 2019 at 4:06 PM Ken Dreyer <kdreyer@redhat.com> wrote:
On Tue, Sep 17, 2019 at 8:03 AM Sasha Litvak
<alexander.v.litvak@gmail.com> wrote:
>
> * I am bothered with a quality of the releases of a very complex system that
> can bring down a whole house and keep it down for a while.  While I wish the
> QA would be perfect, I wonder if it would be practical to release new
> packages to a testing repo before moving it to a main one.  There is a
> chance then someone will detect a problem before it becomes a production
> issue.  Let it seat for a couple days or weeks in testing.  People who need
> new update right away or just want to test will install it and report the
> problems.  Others will not be affected.

I think it would be a good step forward to have a separate "testing"
repository. This repository would be a little more cutting-edge, and we'd copy
all the binaries over to the "main" repository location after 48 hours or
something.

This would let us all publicly test the candidate GPG-signed packages, for
example.

- Ken
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-leave@ceph.io