From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Turner Subject: Re: download.ceph.com repository changes Date: Tue, 24 Sep 2019 17:35:18 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6979016456704826185==" Return-path: In-Reply-To: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: To: Ken Dreyer Cc: ceph-maintainers-Qp0mS5GaXlQ@public.gmane.org, ceph-users , ceph-devel List-Id: ceph-devel.vger.kernel.org --===============6979016456704826185== Content-Type: multipart/alternative; boundary="000000000000c1a45905935350f3" --000000000000c1a45905935350f3 Content-Type: text/plain; charset="UTF-8" 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 wrote: > On Tue, Sep 17, 2019 at 8:03 AM Sasha Litvak > 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-a8pt6IJUokc@public.gmane.org > To unsubscribe send an email to ceph-users-leave-a8pt6IJUokc@public.gmane.org > --000000000000c1a45905935350f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IRT a testing/cutting edge repo, the non-LTS versions of C= eph have been removed because very few people ever used them and tested the= m. The majority of people that would be using the testing repo would be peo= ple needing a bug fix ASAP. Very few people would actually use this regular= ly and its effectiveness would be almost zero in preventing problems slippi= ng through.

At work I haven't had a problem with whi= ch 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 read= y to test a new version in our QA environments long before we promote the v= ersion for production use. That said, I've been bit by this multiple ti= mes 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 f= inish 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 sp= ecify a different version of a package in the repo.

Problem releases have become more problematic than needed because the pac= kages were left the default packages after a bug was known because there wa= s no way to remove them from the repo. People continue to see the upgrade a= nd 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 f= or at least 2 weeks after it's been released even in my testing cluster= s.

On Tue, Sep 24, 2019 at 4:06 PM Ken Dreyer <kdreyer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
On Tue, Sep 17, 2019 at 8:03 AM Sasha L= itvak
<alexa= nder.v.litvak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> * I am bothered with a quality of the releases of a very complex syste= m that
> can bring down a whole house and keep it down for a while.=C2=A0 While= I wish the
> QA would be perfect, I wonder if it would be practical to release new<= br> > packages to a testing repo before moving it to a main one.=C2=A0 There= is a
> chance then someone will detect a problem before it becomes a producti= on
> issue.=C2=A0 Let it seat for a couple days or weeks in testing.=C2=A0 = People who need
> new update right away or just want to test will install it and report = the
> problems.=C2=A0 Others will not be affected.

I think it would be a good step forward to have a separate "testing&qu= ot;
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<= br> example.

- Ken
_______________________________________________
ceph-users mailing list -- ceph-users-a8pt6IJUokc@public.gmane.org
To unsubscribe send an email to ceph-users-leave-a8pt6IJUokc@public.gmane.org
--000000000000c1a45905935350f3-- --===============6979016456704826185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ceph-users mailing list -- ceph-users-a8pt6IJUokc@public.gmane.org To unsubscribe send an email to ceph-users-leave-a8pt6IJUokc@public.gmane.org --===============6979016456704826185==--