[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 à 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 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.

-- 
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/20201211/f71dc6f1/attachment.sig>