[Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/

[Michael Scherer]

Le vendredi 11 décembre 2020 à 13:53 +0100, Michael Scherer a écrit :
> Le vendredi 11 décembre 2020 à 11:43 +0100, Michael Scherer a écrit :
> > Le vendredi 11 décembre 2020 à 16:01 +0530, Amar Tumballi a écrit :
> > > On Thu, Dec 10, 2020 at 11:22 PM Michael Scherer <
> > > mscherer at redhat.com
> > > > 
> > > 
> > > wrote:
> > > 
> > > > Le jeudi 10 décembre 2020 à 22:06 +0530, sankarshan a écrit :
> > > > > What is your recommendation? As in, the next steps from here.
> > > > 
> > > > - check if there is c8s image on amazon already
> > > > 
> > > > if there is one
> > > > - switch the image and reinstall the builders (3rd time this
> > > > week,
> > > > so I
> > > > should not stumble like the previous 2)
> > > > 
> > > > if not
> > > > - install centos8-stream-release rpm, dnf upgrade -y, reboot
> > > > - add the rpm in ansible so it will be here if we reinstall
> > > > - wait for a proper ec2 image and add it to ansible
> > > > 
> > > > Given we had kernel bugs in the past (
> > > > https://github.com/gluster/glusterfs/issues/1402#issuecomment-666358241
> > > >  ), I think  faster access to fixes for the CI (or even for
> > > > production)
> > > > is a good idea.
> > > > 
> > > > 
> > > 
> > > Please go ahead! This looks like a good plan to be adhering to
> > > the
> > > centos
> > > stream... For me,  from outside, centos8-stream is similar to
> > > fedora
> > > rawhide, a moving base.
> > 
> > On the delivery, yeah. But centos-stream is not going to get any
> > radical update, because things go to RHEL after. There is internal
> > gating in place to verify the ABI (and kABI) is not broken, and
> > people
> > aren't going to push "latest upstream" version unlike Rawhide. And
> > the
> > process of deciding what feature go, and what can be supported is
> > still
> > the same. 
> > 
> > But for example, something like 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1762161#c0 would be
> > easier
> > to correct, since we would have to wait for RHEL release (and/or
> > exfiltrate kernel rpms from the intranet)
> > 
> > 
> > I understand why folks make a fuzz about c8s (our com was not
> > great,
> > to
> > say the least...), but in practice, that's just swapping RHEL and
> > Centos order in the pipeline (before, stuff went to RHEL, then got
> > rebuild by Centos, now that will be the reverse, more or less).
> 
> So I went ahead, and it seems device-mapper-devel is missing:
> # LC_ALL=C dnf download device-mapper-devel
> Last metadata expiration check: 1:23:01 ago on Fri Dec 11 11:13:57
> 2020.
> No package device-mapper-devel available.
> Exiting due to strict setting.
> Error: No package device-mapper-devel available.
> 
> There is no lvm2 source on distgit for now (which is sad, but I know
> that's a ongoing effort): 
> https://git.stg.centos.org/rpms/lvm2/branches

So, lvm2 is here, just not on the staging server. And the fact that by
default, the branch show is empty is also not great for discovery.


> So I looked in the internal repo, and there is nothing in the spec
> file
> that disable that rpm.
> 
> On a RHEL 8, that's part of the "codeready-builder-for-rhel-8-x86_64-
> rpms" repo, so I guess that until that part is fixed in Stream,
> that's
> not suitable for building. 
> 
> Ergo, I am reinstalling that builder for the 3rd time this week, and
> I
> will report to who it may concern internally.

Folks pointed out that coderead-builder rpms are in the powertools
repo. And the current FAQ do not point that you have to reenable it
after migration (cause we enable it by ansible, but since the repo name
changed, the new one is disabled after upgrade). 

So I switch the 2 builders and rebooted it without trouble once I
enabled that. 

If there is any issue, please fill tickets.

-- 
Michael Scherer / He/Il/Er/Él
Sysadmin, Community Infrastructure



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.gluster.org/pipermail/gluster-infra/attachments/20201214/da608cf1/attachment.sig>