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:
- construct my spec file(s) locally or over ssh.
- build srpms on a system <out_in_the_world>
- put srpms in a webaccessible location
- paste the srpm urls into the box
- wait for builds
- 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.