Network setup of builders

Miroslav Suchý msuchy at
Thu Jun 27 08:58:09 UTC 2013

On 06/26/2013 10:03 PM, seth vidal wrote:
> Which is the point. That really only lets you build from the blessed
> locations. It's an extra bit of red tape to cut through. Why would we
> want to restrict our users in that way?

If you (and others) really want this feature. What about that you 
provide URL to that repo. It will be synced to copr and then builder 
will use the synced repo?

> Have you uploaded a 1GB file to a website from a home network
> connection? It's AWFUL. Not to mention we'd need to store this one the

Yes. I uploaded even 100 GB.

> -fe system and the whole goal was to have a separation between -fe and
> -be so they didn't need to communicate in anyway but, ultimately REST

Why is there such requirement?

> Here's how I would use this:
> 1. construct my spec file(s) locally or over ssh.
> 2. build srpms on a system <out_in_the_world>
> 3. put srpms in a webaccessible location
> 4. paste the srpm urls into the box
> 5. wait for builds
> 6. win

On the other hand I always build srpms on local system (which is usually 
behind NAT or restrictive firewall). So *I* prefer upload rather then 
scp somewhere and pasting URL. Yes uploading over http have little 
overhead, but is is just multiply by some constant, so not interesting 
from complexity POV.

> Our existing private cloud infrastructure has some space - but not
> infinite space. The answer I was given was - if this is useful we'll be

Can we know the order of "some space"? Is it MB, GB, TB or PB?

> I have no idea what OBS has to do with this.
> Could you explain what you're talking about here?

Because it have same purpose, same goal, same requirements. And it is 
running for some time. So it can give us idea where we can be one or two 
years from now.

> Off the top of my head I can think of a couple of trivial ways to
> verify that the places we're pulling from are repos and not
> random websites - whitelisting them through.

You mean on the iptables level? I would not call that trivial.

> Also - why are you so adamant about this? Maybe I'm misunderstanding
> your tone.

Adamant? Nope. I'm just playing devils advocate.
I'm trying to look on COPR from different angles and I'm thinking loudly.
I would rather be prepared for scenario, which will never happen than 
experience issue for which we will not be prepared.

> The whole point of this is to allow steaming pile of crap packages to
> be built, if people so choose.
> COPRs exists b/c the packaging policies of various bodies are too
> strict and are a barrier to entry. The Powers-That-Be wanted a place
> where people could build whatever package they wanted to build and not
> be hampered by bundling or bad build processes or anything.

Really? That differ from my expectations. I do not want to encourage 
people to build crap (by allowing them to).
Maybe it is time to recap what are the primary target audience of Copr. 
At least how I feel it, because I never seen that written or discussed:

1) various upstream projects (e.g OpenShift, Katello, etc. - but even 
small one man projects), which want to build theirs nightlies in 
reproducible manner.
2) projects which consist of lot of packages and it would take long time 
for them to go through Package Review process (either because it is 
simply too much packages or because they are e.g. bundling libraries and 
it takes some time to fix the code to follow Fedora guideliness) and 
they want to offer their releases right now.
3) Projects which want to offer release for different platform than 
Fedora/EPEL. E.g. Suse, but I would count here even Software 
Collections, Secondary Architectures.
4) Repos which should be private for some reasons (embargoed builds 
which should be tested)

Do I perceive it correctly? Feel free to correct me or add what I'm missing.

Miroslav Suchy
Red Hat Systems Management Engineering

More information about the copr-devel mailing list