Re: MBI (Playground 2.0)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, 1 Feb 2019 at 08:17, Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
On Fri, Feb 1, 2019 at 2:28 AM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
>
> On 1/31/19 4:52 PM, Neal Gompa wrote:
>
> ...snip...
>
> > COPR was supposed to be that outlet, but no one gives a damn about it.
> > Everyone complains that the service is "bad" and that the design is
> > "bad" but no one wants to actually constructively improve it. The
> > quality of service on COPR has fallen due to lack of care and
> > unwillingness to invest, so what are we supposed to do? The horrible
>
> I've heard you and some others say this, but can you perhaps expand on
> it? How has quality of service of copr fallen?

There are some of current/recent major problems with COPR that did not
exist initially:

- builds failing due to failure to download packages from official
Fedora mirror dl.fedoraproject.org

This one is on us in infrastructure.  The problem is mainly because dl was never scoped or built to handle the load that COPR brings. It is meant to mostly deal with yum updates of last resort and mirror traffic. When a bunch of COPR builds happen it gets overloaded and will drop those. It does need to be fixed for this... but the MBI or similar tools will run into this also. 
 
The others I can't really speak for (beyond the disk space where Infrastructure provides an equallogics and it would need a budget increase to get more space.)


- builds failing due to problems with keygen (was not a problem before
keygen was introduced)
- builds failing to import to COPR distgit (was not a problem before
dist-git was introduced)
- outages caused by read-only filesystem after reboot - copr is
unusable until someone remounts it rw
- multi-day long outages caused by out of disk space
- multi-hour or even day- long build queues
- outdated SOP preventing non-COPR people like me from fixing COPR outages

--
Mikolaj
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx


--
Stephen J Smoogen.

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux