#661 Supporting src.fedoraproject.org in CBS
Closed: Insufficient Data 6 months ago by zlopez. Opened 2 years ago by ngompa.

A lot of Hyperscale packages are merely backports from Fedora, and it would be great if we could simply build from src.fedoraproject.org for those packages.

As our group already requires EPEL and we contribute actively to both Fedora and CentOS, it would be tremendously beneficial if we could access Fedora's Dist-Git system for package builds in CBS.

This would also allow us to more strongly encourage people to contribute new packages to Fedora first, because we would be able to say stuff has to work in Fedora before we build it for Hyperscale in CBS.

cc: @dcavalca @salimma @davdunc


We could cover this case by having SIG spaces mirror Fedora dist-git content into their spaces on Gitlab once those are ready. Gitlab has the ability to mirror branches from external systems which would keep the content close to packages the SIG modifies/maintains while still pulling others from Fedora. I think it's important for SIGs to keep their sources discoverable together, even if that means mirroring.

Metadata Update from @bstinson:
- Issue assigned to bstinson

2 years ago

We could cover this case by having SIG spaces mirror Fedora dist-git content into their spaces on Gitlab once those are ready. Gitlab has the ability to mirror branches from external systems which would keep the content close to packages the SIG modifies/maintains while still pulling others from Fedora. I think it's important for SIGs to keep their sources discoverable together, even if that means mirroring.

That would accomplish nothing particularly useful, because people would think that they could contribute there. And I don't want that at all. The thing is, we allow people to build from SRPMs in CBS, so extending CBS to access src.fedoraproject.org as a trusted source is not worse than that. Not to mention, unlike gitlab.com, src.fedoraproject.org is on fully trusted internal infrastructure. It has the same protections that git.centos.org has.

Metadata Update from @zlopez:
- Issue tagged with: cbs, feature-request

2 years ago

src.fedoraproject.org and CBS are not anywhere near each other and do not have a way to be easily connected network wise. [CBS is not in just a different data-centre but it is also not on any internal networks.] This means they are also in two different data privacy and policy zones in respect to various regulations and rules.

Also while the spec files in src.fedoraproject.org are in a git, the look-aside cache is on separate storage which again is not easily shared to CBS. Mirroring of the data is the only way to deal with the firewall and regulations in any near period of time (aka 1-3 years). Anything else is going to take lots of planning, lots of capital and operational expenses and lots of time/energy from sysadmins, accounting etc.

Edit to add: I probably misinterpreted the request so the entire above is not valid.

I just want for Hyperscale backports to have people just go to src.fedoraproject.org and have CBS request stuff from there when we build from there. Nothing more.

That's just adding fedpkg-minimal code to the get sources script and adding src.fedoraproject.org to the CBS Koji allowlist.

To elaborate on this: the idea here is to avoid needless duplication for things like https://git.centos.org/rpms/ethtool/commits/c8s-sig-hyperscale which are straight imports from Fedora with no CentOS-specific changes.

SIGs shouldn't rely on building from SRPM, we'd really like to get comfortable enough to turn that off.

src.fedoraproject.org and gitlab.com are trusted differently from our use here, but that's a detail you shouldn't need to worry about.

My concern is bifurcating the SIG's work, it's absolutely a good idea to have contributors do their work in Fedora, but the SIG needs to maintain control exactly over the code that it ships. The best way to do that is to mirror from Fedora and colocate sources with SIG-generated code.

Adding yet another forge and lookaside is going the wrong direction in terms of simplifying things from an infrastructure and workflow perspective.

SIGs shouldn't rely on building from SRPM, we'd really like to get comfortable enough to turn that off.

src.fedoraproject.org and gitlab.com are trusted differently from our use here, but that's a detail you shouldn't need to worry about.

I think I do have to care because you're using it partly as justification to not do this.

My concern is bifurcating the SIG's work, it's absolutely a good idea to have contributors do their work in Fedora, but the SIG needs to maintain control exactly over the code that it ships. The best way to do that is to mirror from Fedora and colocate sources with SIG-generated code.

Adding yet another forge and lookaside is going the wrong direction in terms of simplifying things from an infrastructure and workflow perspective.

Look at it from my perspective: the Hyperscale SIG is forward-looking by design. Our goal is to focus on the future of the Enterprise Linux platform and bring that to CentOS users today. That's why we rely on EPEL content and that's why we require justifying forking packages from Fedora before even doing it. Today, we have some packages that are literally just SRPM imports from Fedora to build. We'd like to build for Fedora and ELN and just trigger a build from the commit in src.fedoraproject.org in CBS. That will drastically lower the burden for backports from Fedora to CentOS Stream, especially for packages that don't exist in CentOS now (like compsize).

SIGs shouldn't rely on building from SRPM, we'd really like to get comfortable enough to turn that off.

To be clear, in Hyperscale we only use SRPM builds for testing (as scratch builds), and do all our real builds from git. This is where this request is coming from: it'd be useful to do git builds from src.fp.o on CBS for straight imports.

@bstinson Anything you want to add to this ticket? Otherwise we will close it.

Closing as there is no response from assignee.

Metadata Update from @zlopez:
- Issue close_status updated to: Insufficient Data
- Issue status updated to: Closed (was: Open)

6 months ago

Login to comment on this ticket.

Metadata
Boards 1
CBS Status: Backlog