Dear All,
I'd like to retake a pending issue with -extras on c7 and ask for feedback.
I wear two hats : 1/ User, who would like to use altarch-extras packages soon after they are available in c7-extras. 2/ CBS maintainer, who would like to provide his users consistent buildroot across all architecture.
Let's start with 1/. The important point here is to be able to rely on altarch-extras and expect it to be in sync with c7-extras in a reasonable time. (days not weeks) As it was always stated c7 (all repositories) cannot and should not be blocked by any alt-arch rebuild and should be independent. However we should at least try to provide these alt-arches packages in a timely manner.
A lot of coordination (and motivated contributors) is needed if this effort is not centralized.
For 2/ it is very important that we build package with similar buildroots on all arches. As c7-extras is now enabled for everybody, we should be able to have the altarch equivalent in a timely manner. Also all SIGs who are building for all alt-arches will be blocked in case an extras package is needed in the buildroot (we dealt with these issues during 7.2 -> 7.3 cycle and it will come back at next minor release. Additional challenge is the -cr repository which is enabled in CBS by default)
However I understand, we need a way not to block official c7 arches for other arches that need fixes.
After reviewing the possibilities with different people last year, one way to tackle this issue, would be to have 2 targets in Koji ; 1 including official arches and the other including official arches + alt-arches and allow SIG to bypass alt-arches by changing one target in their config. In this config we could move easily an altarch to an official one and vice versa.
Finally, in my opinion, an easy way to have consistent altarch-extras would be to monitor official repository on the mirror.c.o (or buildlogs.c.o) and rebuild automatically extras packages in Koji, which would be picked by a script and so all altarch-extras would be generated directly by Koji itself and the process pretty much automated.
The signing process will still be the key to control what is pushed to buildlogs/mirrors. (and close to what we already do)
I don't see many disadvantages for this solution but I would like to know if it is possible to move forward and what the community and core contributors think about it.
Is altarch-extras important to you ?
thank you for your feedback,
Personnaly I'm waiting for a while for 32bits packages in extra "and" Epel. So, I will appreciate.
De : Thomas Oulevey thomas.oulevey@cern.ch À : The CentOS developers mailing list. centos-devel@centos.org Envoyé le : Lundi 13 mars 2017 21h10 Objet : [CentOS-devel] CentOS 7 extras for alternative arches and Koji workflow.
Dear All,
I'd like to retake a pending issue with -extras on c7 and ask for feedback.
I wear two hats : 1/ User, who would like to use altarch-extras packages soon after they are available in c7-extras. 2/ CBS maintainer, who would like to provide his users consistent buildroot across all architecture.
Let's start with 1/. The important point here is to be able to rely on altarch-extras and expect it to be in sync with c7-extras in a reasonable time. (days not weeks) As it was always stated c7 (all repositories) cannot and should not be blocked by any alt-arch rebuild and should be independent. However we should at least try to provide these alt-arches packages in a timely manner.
A lot of coordination (and motivated contributors) is needed if this effort is not centralized.
For 2/ it is very important that we build package with similar buildroots on all arches. As c7-extras is now enabled for everybody, we should be able to have the altarch equivalent in a timely manner. Also all SIGs who are building for all alt-arches will be blocked in case an extras package is needed in the buildroot (we dealt with these issues during 7.2 -> 7.3 cycle and it will come back at next minor release. Additional challenge is the -cr repository which is enabled in CBS by default)
However I understand, we need a way not to block official c7 arches for other arches that need fixes.
After reviewing the possibilities with different people last year, one way to tackle this issue, would be to have 2 targets in Koji ; 1 including official arches and the other including official arches + alt-arches and allow SIG to bypass alt-arches by changing one target in their config. In this config we could move easily an altarch to an official one and vice versa.
Finally, in my opinion, an easy way to have consistent altarch-extras would be to monitor official repository on the mirror.c.o (or buildlogs.c.o) and rebuild automatically extras packages in Koji, which would be picked by a script and so all altarch-extras would be generated directly by Koji itself and the process pretty much automated.
The signing process will still be the key to control what is pushed to buildlogs/mirrors. (and close to what we already do)
I don't see many disadvantages for this solution but I would like to know if it is possible to move forward and what the community and core contributors think about it.
Is altarch-extras important to you ?
thank you for your feedback,
On 13/03/17 21:10, Thomas Oulevey wrote:
Dear All,
I'd like to retake a pending issue with -extras on c7 and ask for feedback.
I wear two hats : 1/ User, who would like to use altarch-extras packages soon after they are available in c7-extras. 2/ CBS maintainer, who would like to provide his users consistent buildroot across all architecture.
Let's start with 1/. The important point here is to be able to rely on altarch-extras and expect it to be in sync with c7-extras in a reasonable time. (days not weeks) As it was always stated c7 (all repositories) cannot and should not be blocked by any alt-arch rebuild and should be independent. However we should at least try to provide these alt-arches packages in a timely manner.
A lot of coordination (and motivated contributors) is needed if this effort is not centralized.
For 2/ it is very important that we build package with similar buildroots on all arches. As c7-extras is now enabled for everybody, we should be able to have the altarch equivalent in a timely manner. Also all SIGs who are building for all alt-arches will be blocked in case an extras package is needed in the buildroot (we dealt with these issues during 7.2 -> 7.3 cycle and it will come back at next minor release. Additional challenge is the -cr repository which is enabled in CBS by default)
However I understand, we need a way not to block official c7 arches for other arches that need fixes.
After reviewing the possibilities with different people last year, one way to tackle this issue, would be to have 2 targets in Koji ; 1 including official arches and the other including official arches + alt-arches and allow SIG to bypass alt-arches by changing one target in their config. In this config we could move easily an altarch to an official one and vice versa.
Finally, in my opinion, an easy way to have consistent altarch-extras would be to monitor official repository on the mirror.c.o (or buildlogs.c.o) and rebuild automatically extras packages in Koji, which would be picked by a script and so all altarch-extras would be generated directly by Koji itself and the process pretty much automated.
The signing process will still be the key to control what is pushed to buildlogs/mirrors. (and close to what we already do)
I don't see many disadvantages for this solution but I would like to know if it is possible to move forward and what the community and core contributors think about it.
Is altarch-extras important to you ?
thank you for your feedback,
Thanks a lot Thomas for the thread around AltArch and Extras. It's true that it needs to be debated, and each attempt to do it through weekly CBS meeting fails because SIGs aren't present, nor people building/releasing for Extras either.
So my understanding is that the problem relies on the fact that there isn't even a policy around Extras repository now. So it's up to the people allowed to build/sign/push to know what they'll add in Extras, and only in the arches they care about.
CBS isn't authoritative for Core distro nor Extras, so that will be a problem. I can understand that distro itself is built on a separate environment (but still separated for *every* arch, which isn't ideal either ...) but can we think about building Extras directly through CBS ? What's the reason why we don't do this right now ? if we include Extras in the mock buildroots for cbs, people using multiple arches should expect indeed the same packages to be available (if not excluded due to ExclusiveArch of course).
As a simple example, in the last weeks we (infra team) had issue with the simple koji upgrade/update as some pkgs were built for x86_64 extras, but not other arches, so we had in a hurry to build missing pieces to then be able to just update koji (as we have builders for AltArches that *need* to follow now)
I personally don't like the "let's track what's released on mirror.centos.org extras and rebuild it afterwards in cbs" idea : doesn't that sound counter-productive to wait for a core maintainer to build on his own, sign, push to mirror and only after rebuilding again the same thing in cbs ? If we can build it once, it's true that we can (re)build it multiple times, but not sure about the "win" :)
Also myself waiting for opinions/feedback on this
On 15/03/17 09:28, Fabian Arrotin wrote:
So my understanding is that the problem relies on the fact that there isn't even a policy around Extras repository now. So it's up to the people allowed to build/sign/push to know what they'll add in Extras, and only in the arches they care about.
https://wiki.centos.org/AdditionalResources/Repositories has a definition for the Extras repos. on C7 it should include what is upstream in the Extras/ repos ( provided we are able to build it ), and other things that are needed sometimes to build content in base / updates.
In addition to this, Extras should contain all centos-release-* files from the SIG's.
The only other content that should make it into Extras should be content vetted by the core sig, considered fundamental to user experience or tooling for user experience. ie. a fairly high barrier to entry.
Does that give us enough policy wording for Extras ? Do we have exceptions we need to work through ?
On 15/03/17 16:58, Karanbir Singh wrote:
On 15/03/17 09:28, Fabian Arrotin wrote:
So my understanding is that the problem relies on the fact that there isn't even a policy around Extras repository now. So it's up to the people allowed to build/sign/push to know what they'll add in Extras, and only in the arches they care about.
https://wiki.centos.org/AdditionalResources/Repositories has a definition for the Extras repos. on C7 it should include what is upstream in the Extras/ repos ( provided we are able to build it ), and other things that are needed sometimes to build content in base / updates.
In addition to this, Extras should contain all centos-release-* files from the SIG's.
The only other content that should make it into Extras should be content vetted by the core sig, considered fundamental to user experience or tooling for user experience. ie. a fairly high barrier to entry.
Does that give us enough policy wording for Extras ? Do we have exceptions we need to work through ?
Sounds good. So with that definition in mind, how can we be sure that Extras is then built/distributed in parallel for all arches, so that then it can be safely enabled within CBS ?
On Thu, Mar 16, 2017 at 6:17 PM, Fabian Arrotin arrfab@centos.org wrote:
On 15/03/17 16:58, Karanbir Singh wrote:
On 15/03/17 09:28, Fabian Arrotin wrote:
So my understanding is that the problem relies on the fact that there isn't even a policy around Extras repository now. So it's up to the people allowed to build/sign/push to know what they'll add in Extras, and only in the arches they care about.
https://wiki.centos.org/AdditionalResources/Repositories has a definition for the Extras repos. on C7 it should include what is upstream in the Extras/ repos ( provided we are able to build it ), and other things that are needed sometimes to build content in base /
updates.
In addition to this, Extras should contain all centos-release-* files from the SIG's.
The only other content that should make it into Extras should be content vetted by the core sig, considered fundamental to user experience or tooling for user experience. ie. a fairly high barrier to entry.
Does that give us enough policy wording for Extras ? Do we have exceptions we need to work through ?
Sounds good. So with that definition in mind, how can we be sure that Extras is then built/distributed in parallel for all arches, so that then it can be safely enabled within CBS ?
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Adding here notes I sent in a different thread, for reference. I'm facing some discrepancies in repositories structure for ppc64le.
In x86_64 qemu-kvm-ev is shipped within http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ which is the path I was expecting. Now, looking at ppc64le I see it shipped within: http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ and being extras enabled by default it overrides qemu-kvm shipped by core os. Can we at least replicate the same structure between http://mirror.centos.org/centos/7 and http://mirror.centos.org/altarch/7 ?
next, I see cockpit available for x86_64 in http://mirror.centos.org/centos/7/extras/x86_64/Packages/ but it's missing in http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/
I see cockpit in fedora ppc64le: https://koji.fedoraproject.org/koji/ buildinfo?buildID=869569 so it should be possible to get it on centos as well. Can you please build it?
On Fri, Mar 17, 2017 at 10:49 AM, Sandro Bonazzola sbonazzo@redhat.com wrote:
On Thu, Mar 16, 2017 at 6:17 PM, Fabian Arrotin arrfab@centos.org wrote:
On 15/03/17 16:58, Karanbir Singh wrote:
On 15/03/17 09:28, Fabian Arrotin wrote:
So my understanding is that the problem relies on the fact that there isn't even a policy around Extras repository now. So it's up to the people allowed to build/sign/push to know what they'll add in Extras, and only in the arches they care about.
https://wiki.centos.org/AdditionalResources/Repositories has a definition for the Extras repos. on C7 it should include what is upstream in the Extras/ repos ( provided we are able to build it ), and other things that are needed sometimes to build content in base /
updates.
In addition to this, Extras should contain all centos-release-* files from the SIG's.
The only other content that should make it into Extras should be content vetted by the core sig, considered fundamental to user experience or tooling for user experience. ie. a fairly high barrier to entry.
Does that give us enough policy wording for Extras ? Do we have exceptions we need to work through ?
Sounds good. So with that definition in mind, how can we be sure that Extras is then built/distributed in parallel for all arches, so that then it can be safely enabled within CBS ?
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Adding here notes I sent in a different thread, for reference. I'm facing some discrepancies in repositories structure for ppc64le.
In x86_64 qemu-kvm-ev is shipped within http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ which is the path I was expecting. Now, looking at ppc64le I see it shipped within: http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ and being extras enabled by default it overrides qemu-kvm shipped by core os. Can we at least replicate the same structure between http://mirror.centos.org/centos/7 and http://mirror.centos.org/altarch/7 ?
Any update?
next, I see cockpit available for x86_64 in http://mirror.centos.org/centos/7/extras/x86_64/Packages/ but it's missing in http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/
I see cockpit in fedora ppc64le: https://koji.fedorapr oject.org/koji/buildinfo?buildID=869569 so it should be possible to get it on centos as well. Can you please build it?
Any update?
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 08/05/17 13:44, Sandro Bonazzola wrote:
On Fri, Mar 17, 2017 at 10:49 AM, Sandro Bonazzola <sbonazzo@redhat.com mailto:sbonazzo@redhat.com> wrote:
On Thu, Mar 16, 2017 at 6:17 PM, Fabian Arrotin <arrfab@centos.org <mailto:arrfab@centos.org>> wrote: On 15/03/17 16:58, Karanbir Singh wrote: > On 15/03/17 09:28, Fabian Arrotin wrote: > >> So my understanding is that the problem relies on the fact that there >> isn't even a policy around Extras repository now. So it's up to the >> people allowed to build/sign/push to know what they'll add in Extras, >> and only in the arches they care about. > > https://wiki.centos.org/AdditionalResources/Repositories <https://wiki.centos.org/AdditionalResources/Repositories> has a > definition for the Extras repos. on C7 it should include what is > upstream in the Extras/ repos ( provided we are able to build it ), and > other things that are needed sometimes to build content in base / updates. > > In addition to this, Extras should contain all centos-release-* files > from the SIG's. > > The only other content that should make it into Extras should be content > vetted by the core sig, considered fundamental to user experience or > tooling for user experience. ie. a fairly high barrier to entry. > > Does that give us enough policy wording for Extras ? Do we have > exceptions we need to work through ? > Sounds good. So with that definition in mind, how can we be sure that Extras is then built/distributed in parallel for all arches, so that then it can be safely enabled within CBS ? -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org <mailto:CentOS-devel@centos.org> https://lists.centos.org/mailman/listinfo/centos-devel <https://lists.centos.org/mailman/listinfo/centos-devel> Adding here notes I sent in a different thread, for reference. I'm facing some discrepancies in repositories structure for ppc64le. In x86_64 qemu-kvm-ev is shipped within http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ <http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/> which is the path I was expecting. Now, looking at ppc64le I see it shipped within: http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ <http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/> and being extras enabled by default it overrides qemu-kvm shipped by core os. Can we at least replicate the same structure between http://mirror.centos.org/centos/7 <http://mirror.centos.org/centos/7> and http://mirror.centos.org/altarch/7 <http://mirror.centos.org/altarch/7> ?Any update?
have you tried to reach out to the SIG's responsible for the content ?
next, I see cockpit available for x86_64 in http://mirror.centos.org/centos/7/extras/x86_64/Packages/ <http://mirror.centos.org/centos/7/extras/x86_64/Packages/> but it's missing in http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ <http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/> I see cockpit in fedora ppc64le: https://koji.fedoraproject.org/koji/buildinfo?buildID=869569 <https://koji.fedoraproject.org/koji/buildinfo?buildID=869569> so it should be possible to get it on centos as well. Can you please build it?Any update?
we build parts of cockpit as a part of the atomic stack - since thats not on PPC, i think you might need to setup a suiteable target and maintain that yourself - the atomic stack isnt going to be able to do this.
regards
On 18/05/17 00:49, Karanbir Singh wrote:
On 08/05/17 13:44, Sandro Bonazzola wrote:
On Fri, Mar 17, 2017 at 10:49 AM, Sandro Bonazzola <sbonazzo@redhat.com mailto:sbonazzo@redhat.com> wrote:
On Thu, Mar 16, 2017 at 6:17 PM, Fabian Arrotin <arrfab@centos.org <mailto:arrfab@centos.org>> wrote: On 15/03/17 16:58, Karanbir Singh wrote: > On 15/03/17 09:28, Fabian Arrotin wrote: > >> So my understanding is that the problem relies on the fact that there >> isn't even a policy around Extras repository now. So it's up to the >> people allowed to build/sign/push to know what they'll add in Extras, >> and only in the arches they care about. > > https://wiki.centos.org/AdditionalResources/Repositories <https://wiki.centos.org/AdditionalResources/Repositories> has a > definition for the Extras repos. on C7 it should include what is > upstream in the Extras/ repos ( provided we are able to build it ), and > other things that are needed sometimes to build content in base / updates. > > In addition to this, Extras should contain all centos-release-* files > from the SIG's. > > The only other content that should make it into Extras should be content > vetted by the core sig, considered fundamental to user experience or > tooling for user experience. ie. a fairly high barrier to entry. > > Does that give us enough policy wording for Extras ? Do we have > exceptions we need to work through ? > Sounds good. So with that definition in mind, how can we be sure that Extras is then built/distributed in parallel for all arches, so that then it can be safely enabled within CBS ? -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org <mailto:CentOS-devel@centos.org> https://lists.centos.org/mailman/listinfo/centos-devel <https://lists.centos.org/mailman/listinfo/centos-devel> Adding here notes I sent in a different thread, for reference. I'm facing some discrepancies in repositories structure for ppc64le. In x86_64 qemu-kvm-ev is shipped within http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ <http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/> which is the path I was expecting. Now, looking at ppc64le I see it shipped within: http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ <http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/> and being extras enabled by default it overrides qemu-kvm shipped by core os. Can we at least replicate the same structure between http://mirror.centos.org/centos/7 <http://mirror.centos.org/centos/7> and http://mirror.centos.org/altarch/7 <http://mirror.centos.org/altarch/7> ?Any update?
have you tried to reach out to the SIG's responsible for the content ?
That's interesting, as for ppc64/ppc64le for AltArch SIG, you're the one responsible KB for those arches (from what I see on https://wiki.centos.org/SpecialInterestGroup/AltArch) So I guess that yes, Sandro tried to reach out and contact you for that question :-)
When it was discussed at the CBS meeting, (but lot of involved people weren't there, it was clearly shown that we lack a process for Extras, and ensuring then than all Alt Arches are following the authoritative x86_64 distro. That was becoming a problem too as in fact, nothing from Extras is built on cbs, but rather on different builders and different processes (so more or less like @core distro)
The issue that people were seeing was that they wanted to have Extras enabled within CBS, but due to lack of consistency in Extras, some builds could fail just because one package is missing from Extras for an arch, while being available for x86_64.
Does that summarize the issue SIGs members reported in #centos-devel but also earlier on this list ?
On Thu, May 18, 2017 at 7:32 AM, Fabian Arrotin arrfab@centos.org wrote:
On 18/05/17 00:49, Karanbir Singh wrote:
On 08/05/17 13:44, Sandro Bonazzola wrote:
On Fri, Mar 17, 2017 at 10:49 AM, Sandro Bonazzola <sbonazzo@redhat.com mailto:sbonazzo@redhat.com> wrote:
On Thu, Mar 16, 2017 at 6:17 PM, Fabian Arrotin <arrfab@centos.org <mailto:arrfab@centos.org>> wrote: On 15/03/17 16:58, Karanbir Singh wrote: > On 15/03/17 09:28, Fabian Arrotin wrote: > >> So my understanding is that the problem relies on the factthat there
>> isn't even a policy around Extras repository now. So it's upto the
>> people allowed to build/sign/push to know what they'll addin Extras,
>> and only in the arches they care about. > > https://wiki.centos.org/AdditionalResources/Repositories <https://wiki.centos.org/AdditionalResources/Repositories> hasa
> definition for the Extras repos. on C7 it should include whatis
> upstream in the Extras/ repos ( provided we are able to buildit ), and
> other things that are needed sometimes to build content inbase / updates.
> > In addition to this, Extras should contain allcentos-release-* files
> from the SIG's. > > The only other content that should make it into Extras shouldbe content
> vetted by the core sig, considered fundamental to userexperience or
> tooling for user experience. ie. a fairly high barrier toentry.
> > Does that give us enough policy wording for Extras ? Do wehave
> exceptions we need to work through ? > Sounds good. So with that definition in mind, how can we be sure that Extras is then built/distributed in parallel for all arches, sothat
then it can be safely enabled within CBS ? -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org <mailto:CentOS-devel@centos.org> https://lists.centos.org/mailman/listinfo/centos-devel <https://lists.centos.org/mailman/listinfo/centos-devel> Adding here notes I sent in a different thread, for reference. I'm facing some discrepancies in repositories structure for ppc64le. In x86_64 qemu-kvm-ev is shipped within http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ <http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/> which is the path I was expecting. Now, looking at ppc64le I see it shipped within: http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ <http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/> and being extras enabled by default it overrides qemu-kvm shipped by core os. Can we at least replicate the same structure between http://mirror.centos.org/centos/7 <http://mirror.centos.org/centos/7> and http://mirror.centos.org/altarch/7
<http://mirror.centos.org/altarch/7> ?Any update?
have you tried to reach out to the SIG's responsible for the content ?
That's interesting, as for ppc64/ppc64le for AltArch SIG, you're the one responsible KB for those arches (from what I see on https://wiki.centos.org/SpecialInterestGroup/AltArch) So I guess that yes, Sandro tried to reach out and contact you for that question :-)
When it was discussed at the CBS meeting, (but lot of involved people weren't there, it was clearly shown that we lack a process for Extras, and ensuring then than all Alt Arches are following the authoritative x86_64 distro. That was becoming a problem too as in fact, nothing from Extras is built on cbs, but rather on different builders and different processes (so more or less like @core distro)
The issue that people were seeing was that they wanted to have Extras enabled within CBS, but due to lack of consistency in Extras, some builds could fail just because one package is missing from Extras for an arch, while being available for x86_64.
Does that summarize the issue SIGs members reported in #centos-devel but also earlier on this list ?
I think it's mostly it. Thanks for summarizing.
-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 05/08/2017 06:14 PM, Sandro Bonazzola wrote:
Adding here notes I sent in a different thread, for reference. I'm facing some discrepancies in repositories structure for ppc64le. In x86_64 qemu-kvm-ev is shipped within http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ <http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/> which is the path I was expecting. Now, looking at ppc64le I see it shipped within: http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/ <http://mirror.centos.org/altarch/7/extras/ppc64le/Packages/> and being extras enabled by default it overrides qemu-kvm shipped by core os. Can we at least replicate the same structure between http://mirror.centos.org/centos/7 <http://mirror.centos.org/centos/7> and http://mirror.centos.org/altarch/7 <http://mirror.centos.org/altarch/7> ?Any update?
This is partly required for ppc64le and aarch64 as well (I do this in aarch64 as well). Both require, and are built against the newer/sig qemu-kvm-ev, because the upstream RH release builds them against qemu-kvm-rhev rather than the older distro qemu-kvm. There are a number of distro components built against them, so it's needed for repoclosure.
On Mon, Mar 13, 2017 at 09:10:32PM +0100, Thomas Oulevey wrote:
Dear All,
I'd like to retake a pending issue with -extras on c7 and ask for feedback.
I wear two hats : 1/ User, who would like to use altarch-extras packages soon after they are available in c7-extras. 2/ CBS maintainer, who would like to provide his users consistent buildroot across all architecture.
Let's start with 1/. The important point here is to be able to rely on altarch-extras and expect it to be in sync with c7-extras in a reasonable time. (days not weeks) As it was always stated c7 (all repositories) cannot and should not be blocked by any alt-arch rebuild and should be independent. However we should at least try to provide these alt-arches packages in a timely manner.
A lot of coordination (and motivated contributors) is needed if this effort is not centralized.
It would be really nice to have this available. Personally I care most for armv7hl because that is hardware I have and am actively using. Because the process for armv7hl does not seem very automated (or matches the rest of the altarch workflow), I am currently 'stuck' on Fedora.
However there are many others in the Gluster community that run the GlusterFS packages on different hardware. Because CentOS does not provide the repositories (or have not announced it well enough?), I only see non-x86_64 problem reports and questions on other distributions. It would be great to see more Gluster users running on CentOS/altarch.
For 2/ it is very important that we build package with similar buildroots on all arches. As c7-extras is now enabled for everybody, we should be able to have the altarch equivalent in a timely manner. Also all SIGs who are building for all alt-arches will be blocked in case an extras package is needed in the buildroot (we dealt with these issues during 7.2 -> 7.3 cycle and it will come back at next minor release. Additional challenge is the -cr repository which is enabled in CBS by default)
However I understand, we need a way not to block official c7 arches for other arches that need fixes.
For the Gluster repositories from the Storage SIG, it is even acceptible to block on altarch. I think it is unlikely that an update for the packages in the Gluster repositories would introduce new problems with altarch packages, or teh other way around. When there is a major release, new dependencies might be needed, but there should be enough time to get those available in -extras or somewhere else.
After reviewing the possibilities with different people last year, one way to tackle this issue, would be to have 2 targets in Koji ; 1 including official arches and the other including official arches + alt-arches and allow SIG to bypass alt-arches by changing one target in their config. In this config we could move easily an altarch to an official one and vice versa.
I prefer to see everything build (at least for Gluster) against all arches. This is what we do for many other distributions too, and we are committed to fix problems there as well.
Finally, in my opinion, an easy way to have consistent altarch-extras would be to monitor official repository on the mirror.c.o (or buildlogs.c.o) and rebuild automatically extras packages in Koji, which would be picked by a script and so all altarch-extras would be generated directly by Koji itself and the process pretty much automated.
Works for me too, as long as I do not have to take additional actions to get packages available for CentOS/altarch users.
The signing process will still be the key to control what is pushed to buildlogs/mirrors. (and close to what we already do)
I don't see many disadvantages for this solution but I would like to know if it is possible to move forward and what the community and core contributors think about it.
Sounds good, but there is one more thing that needs to be mentioned. I would like to have the ability (I'm pretty sure it is coming?) to test the altarch packages in the CI. It is not an absolute requirement for the beginning, but it is definitely something to consider. It would allow testing interoperability between different architectures (yay for low level network protocols :-/).
Is altarch-extras important to you ?
Yes, and as seen in Sandros email from earlier today, the -extras being out of sync causes problems for some of the SIGs. Thanks for testing Sandro! https://lists.centos.org/pipermail/centos-devel/2017-March/015736.html (+python-pretty-table is missing in -extras.ppc64le for Gluster 3.10)
Cheers, Niels
-
Fabian Arrotin -
Jim Perrin -
john tatt -
Karanbir Singh -
Niels de Vos -
Sandro Bonazzola -
Thomas Oulevey