Network setup of builders
msuchy at redhat.com
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
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.
Red Hat Systems Management Engineering
More information about the copr-devel