Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
We learn about new things each time we do infra changes :) Thanks Michael. Also, as a different topic, please remember to send a note to the list about availability and holidays as the year end comes close. On Mon, 14 Dec 2020 at 16:56, Michael Scherer wrote: > > 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 < > > > > msche...@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 > > > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-infra -- sankars...@kadalu.io | TZ: UTC+0530 | +91 99606 03294 kadalu.io : Making it easy to provision storage in k8s! ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
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 < > > > msche...@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 signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
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 < > > msche...@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 signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
Le vendredi 11 décembre 2020 à 16:01 +0530, Amar Tumballi a écrit : > On Thu, Dec 10, 2020 at 11:22 PM Michael Scherer > > 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). > As long as tests are running fine, we are fine, when it breaks, to > debug, > there are more than glusterfs elements to consider now. -- Michael Scherer / He/Il/Er/Él Sysadmin, Community Infrastructure signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
On Thu, Dec 10, 2020 at 11:22 PM Michael Scherer 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. As long as tests are running fine, we are fine, when it breaks, to debug, there are more than glusterfs elements to consider now. Regards, Amar > On Thu, 10 Dec 2020 at 21:28, Michael Scherer > > wrote: > > > > > > Le jeudi 10 décembre 2020 à 21:14 +0530, sankarshan a écrit : > > > > There are 2 specific bits which I expected to stimulate in > > > > discussion > > > > > > > > [1] a review by the Gluster Infrastructure team in terms of > > > > whether > > > > there is any change in the processes/environment > > > > > > I was about to ask. For now, we run C8 almost nowhere, except 2 > > > builders. > > > > > > I pondered between switching both of them to C8s, or reinstall 2 on > > > C8s > > > and keep 2 on C8, to compare. > > > > > > I do not expect disruptive change on c8s that wouldn't already > > > happen > > > on c8 with a minor version, so I am ok to just switch, I just do > > > not > > > have any Centos 8 to test. > > > > > > > > > > > > > [2] whether the maintainers will consider reviewing this in > > > > entirety > > > > and be able to assess the impact > > > > > > > > To my knowledge this topic was not previously brought up at any > > > > of > > > > the > > > > Gluster meetings, so it is worth requesting all parties involved > > > > to > > > > take a moment to form their opinions and use appropriate forums > > > > to > > > > discuss that. > > > > > > > > On Wed, 9 Dec 2020 at 14:04, Niels de Vos > > > > wrote: > > > > > > > > > > On Tue, Dec 08, 2020 at 09:00:35PM +0530, sankarshan wrote: > > > > > > FYI. Would likely be important in context of packaging, > > > > > > testing > > > > > > and > > > > > > release content > > > > > > > > > > Indeed, we currently build packages in the CentOS Storage SIG > > > > > against > > > > > CentOS Linux, and not against CentOS Stream. But other than > > > > > that, I > > > > > do > > > > > not expect major visible changes for our users. > > > > > > > > > > The main advantage is that we can more directly contribute to > > > > > the > > > > > distribution. CentOS Stream allows us to send PRs that get > > > > > reviewed > > > > > by > > > > > Red Hat Enterprise Linux developers and potentially get > > > > > included. That > > > > > means, enhancements to FUSE or other components do not need to > > > > > rely > > > > > on > > > > > the work Red Hat is planning, but could be worked on by our > > > > > community > > > > > and get included earlier. > > > > > > > > > > If there are any concerns, I'd love to hear about it. > > > > > > > > > > Thanks, > > > > > Niels > > > > > > > > > > > > > > -- > > > Michael Scherer / He/Il/Er/Él > > > Sysadmin, Community Infrastructure > > > > > > > > > > > > > > -- > Michael Scherer / He/Il/Er/Él > Sysadmin, Community Infrastructure > > > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-infra -- -- https://kadalu.io Container Storage made easy! ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
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. On Thu, 10 Dec 2020 at 21:28, Michael Scherer > wrote: > > > > Le jeudi 10 décembre 2020 à 21:14 +0530, sankarshan a écrit : > > > There are 2 specific bits which I expected to stimulate in > > > discussion > > > > > > [1] a review by the Gluster Infrastructure team in terms of > > > whether > > > there is any change in the processes/environment > > > > I was about to ask. For now, we run C8 almost nowhere, except 2 > > builders. > > > > I pondered between switching both of them to C8s, or reinstall 2 on > > C8s > > and keep 2 on C8, to compare. > > > > I do not expect disruptive change on c8s that wouldn't already > > happen > > on c8 with a minor version, so I am ok to just switch, I just do > > not > > have any Centos 8 to test. > > > > > > > > > [2] whether the maintainers will consider reviewing this in > > > entirety > > > and be able to assess the impact > > > > > > To my knowledge this topic was not previously brought up at any > > > of > > > the > > > Gluster meetings, so it is worth requesting all parties involved > > > to > > > take a moment to form their opinions and use appropriate forums > > > to > > > discuss that. > > > > > > On Wed, 9 Dec 2020 at 14:04, Niels de Vos > > > wrote: > > > > > > > > On Tue, Dec 08, 2020 at 09:00:35PM +0530, sankarshan wrote: > > > > > FYI. Would likely be important in context of packaging, > > > > > testing > > > > > and > > > > > release content > > > > > > > > Indeed, we currently build packages in the CentOS Storage SIG > > > > against > > > > CentOS Linux, and not against CentOS Stream. But other than > > > > that, I > > > > do > > > > not expect major visible changes for our users. > > > > > > > > The main advantage is that we can more directly contribute to > > > > the > > > > distribution. CentOS Stream allows us to send PRs that get > > > > reviewed > > > > by > > > > Red Hat Enterprise Linux developers and potentially get > > > > included. That > > > > means, enhancements to FUSE or other components do not need to > > > > rely > > > > on > > > > the work Red Hat is planning, but could be worked on by our > > > > community > > > > and get included earlier. > > > > > > > > If there are any concerns, I'd love to hear about it. > > > > > > > > Thanks, > > > > Niels > > > > > > > > > > -- > > Michael Scherer / He/Il/Er/Él > > Sysadmin, Community Infrastructure > > > > > > > > -- Michael Scherer / He/Il/Er/Él Sysadmin, Community Infrastructure signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
What is your recommendation? As in, the next steps from here. On Thu, 10 Dec 2020 at 21:28, Michael Scherer wrote: > > Le jeudi 10 décembre 2020 à 21:14 +0530, sankarshan a écrit : > > There are 2 specific bits which I expected to stimulate in discussion > > > > [1] a review by the Gluster Infrastructure team in terms of whether > > there is any change in the processes/environment > > I was about to ask. For now, we run C8 almost nowhere, except 2 > builders. > > I pondered between switching both of them to C8s, or reinstall 2 on C8s > and keep 2 on C8, to compare. > > I do not expect disruptive change on c8s that wouldn't already happen > on c8 with a minor version, so I am ok to just switch, I just do not > have any Centos 8 to test. > > > > > [2] whether the maintainers will consider reviewing this in entirety > > and be able to assess the impact > > > > To my knowledge this topic was not previously brought up at any of > > the > > Gluster meetings, so it is worth requesting all parties involved to > > take a moment to form their opinions and use appropriate forums to > > discuss that. > > > > On Wed, 9 Dec 2020 at 14:04, Niels de Vos wrote: > > > > > > On Tue, Dec 08, 2020 at 09:00:35PM +0530, sankarshan wrote: > > > > FYI. Would likely be important in context of packaging, testing > > > > and > > > > release content > > > > > > Indeed, we currently build packages in the CentOS Storage SIG > > > against > > > CentOS Linux, and not against CentOS Stream. But other than that, I > > > do > > > not expect major visible changes for our users. > > > > > > The main advantage is that we can more directly contribute to the > > > distribution. CentOS Stream allows us to send PRs that get reviewed > > > by > > > Red Hat Enterprise Linux developers and potentially get > > > included. That > > > means, enhancements to FUSE or other components do not need to rely > > > on > > > the work Red Hat is planning, but could be worked on by our > > > community > > > and get included earlier. > > > > > > If there are any concerns, I'd love to hear about it. > > > > > > Thanks, > > > Niels > > > > > -- > Michael Scherer / He/Il/Er/Él > Sysadmin, Community Infrastructure > > > -- sankars...@kadalu.io | TZ: UTC+0530 | +91 99606 03294 kadalu.io : Making it easy to provision storage in k8s! ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
Le jeudi 10 décembre 2020 à 21:14 +0530, sankarshan a écrit : > There are 2 specific bits which I expected to stimulate in discussion > > [1] a review by the Gluster Infrastructure team in terms of whether > there is any change in the processes/environment I was about to ask. For now, we run C8 almost nowhere, except 2 builders. I pondered between switching both of them to C8s, or reinstall 2 on C8s and keep 2 on C8, to compare. I do not expect disruptive change on c8s that wouldn't already happen on c8 with a minor version, so I am ok to just switch, I just do not have any Centos 8 to test. > [2] whether the maintainers will consider reviewing this in entirety > and be able to assess the impact > > To my knowledge this topic was not previously brought up at any of > the > Gluster meetings, so it is worth requesting all parties involved to > take a moment to form their opinions and use appropriate forums to > discuss that. > > On Wed, 9 Dec 2020 at 14:04, Niels de Vos wrote: > > > > On Tue, Dec 08, 2020 at 09:00:35PM +0530, sankarshan wrote: > > > FYI. Would likely be important in context of packaging, testing > > > and > > > release content > > > > Indeed, we currently build packages in the CentOS Storage SIG > > against > > CentOS Linux, and not against CentOS Stream. But other than that, I > > do > > not expect major visible changes for our users. > > > > The main advantage is that we can more directly contribute to the > > distribution. CentOS Stream allows us to send PRs that get reviewed > > by > > Red Hat Enterprise Linux developers and potentially get > > included. That > > means, enhancements to FUSE or other components do not need to rely > > on > > the work Red Hat is planning, but could be worked on by our > > community > > and get included earlier. > > > > If there are any concerns, I'd love to hear about it. > > > > Thanks, > > Niels > > -- Michael Scherer / He/Il/Er/Él Sysadmin, Community Infrastructure signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-Maintainers] [gluster-packaging] Fwd: [CentOS-devel] https://blog.centos.org/2020/12/future-is-centos-stream/
There are 2 specific bits which I expected to stimulate in discussion [1] a review by the Gluster Infrastructure team in terms of whether there is any change in the processes/environment [2] whether the maintainers will consider reviewing this in entirety and be able to assess the impact To my knowledge this topic was not previously brought up at any of the Gluster meetings, so it is worth requesting all parties involved to take a moment to form their opinions and use appropriate forums to discuss that. On Wed, 9 Dec 2020 at 14:04, Niels de Vos wrote: > > On Tue, Dec 08, 2020 at 09:00:35PM +0530, sankarshan wrote: > > FYI. Would likely be important in context of packaging, testing and > > release content > > Indeed, we currently build packages in the CentOS Storage SIG against > CentOS Linux, and not against CentOS Stream. But other than that, I do > not expect major visible changes for our users. > > The main advantage is that we can more directly contribute to the > distribution. CentOS Stream allows us to send PRs that get reviewed by > Red Hat Enterprise Linux developers and potentially get included. That > means, enhancements to FUSE or other components do not need to rely on > the work Red Hat is planning, but could be worked on by our community > and get included earlier. > > If there are any concerns, I'd love to hear about it. > > Thanks, > Niels -- sankars...@kadalu.io | TZ: UTC+0530 | +91 99606 03294 kadalu.io : Making it easy to provision storage in k8s! ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
