<div dir="ltr"><div dir="ltr">On Thu, Oct 13, 2022 at 7:24 AM Neal Gompa <<a href="mailto:ngompa13@gmail.com">ngompa13@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Oct 12, 2022 at 2:12 PM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br>
><br>
> On Thu, Oct 13, 2022 at 12:53 AM Neal Gompa <<a href="mailto:ngompa13@gmail.com" target="_blank">ngompa13@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Oct 12, 2022 at 6:23 AM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br>
>> ><br>
>> > Hi all,<br>
>> ><br>
>> > It has come to my attention after noticing abnormal activity on our Gitlab instance this evening that at least one distribution is fetching tarball archives for the KDE Qt Patch Collection directly from Invent.<br>
>> ><br>
>> > This is not a workload that <a href="http://invent.kde.org" rel="noreferrer" target="_blank">invent.kde.org</a> is intended to support and therefore places abnormal load on the system - especially in the case of QtWebEngine due to it's size. Analysis of the logs indicates that this type of activity is being conducted by both an RPM based distribution, as well as by Alpine Linux (see <a href="https://git.alpinelinux.org/aports/tree/community/qt5-qtserialbus/APKBUILD?h=3.16-stable" rel="noreferrer" target="_blank">https://git.alpinelinux.org/aports/tree/community/qt5-qtserialbus/APKBUILD?h=3.16-stable</a>)<br>
>> ><br>
>> > If the above applies to your distribution please ensure that you use your own copies of the tarballs generated by GItlab and do not have your automated tooling fetch it from <a href="http://invent.kde.org" rel="noreferrer" target="_blank">invent.kde.org</a> directly.<br>
>> ><br>
>> > Log excerpts, with IP addresses removed:<br>
>> ><br>
>> > [12/Oct/2022:05:17:59 +0000] "GET /frameworks/karchive/-/archive/8653117dede663d1f20850da82518fff4b7f732d/karchive-8653117.tar.gz HTTP/1.1" 200 1035786 "-" "rpmdev-spectool"<br>
>> > [12/Oct/2022:06:25:03 +0000] "GET /qt/qt/qtwebchannel/-/archive/fa8b07105b5e274daaa8adcc129fa4aa0447f9f7/qtwebchannel-fa8b07105b5e274daaa8adcc129fa4aa0447f9f7.tar.bz2 HTTP/1.1" 200 249616 "-" "Wget/1.21.2"<br>
>> > [11/Oct/2022:15:51:41 +0000] "GET /qt/qt/qtwebengine/-/archive/v5.15.8-lts/qtwebengine-v5.15.8-lts.tar.bz2 HTTP/1.1" 200 3090478 "-" "Wget/1.21"<br>
>> ><br>
>><br>
>> At this time, Fedora does not package snapshots yet, though I believe<br>
>> I know who is doing it based on the log snippet here.<br>
>><br>
>> But I'm going to use this to make a point here: I asked for<br>
>> tag-releases of the KDE Qt patch set earlier this year because the<br>
>> current situation is a huge mess[1]. The advice I continue to receive<br>
>> from KDE developers is to just fetch HEAD and ship that. Aside from<br>
>> being absolutely nuts to keep track of, you're telling us that the KDE<br>
>> GitLab instance can't handle it.<br>
><br>
><br>
> Fetching HEAD, in the form of cloning of the Git repository itself, is something our system is well optimised for and can handle without issue.<br>
> Serving a compressed tarball of the files in that repository however is orders of magnitude more expensive and is not a workflow for which it is optimised to handle, especially not for automated access.<br>
><br>
> It has always been Sysadmin policy that automated access to the repository browser functionality of any of our code repositories is not permitted.<br>
> This has covered /*checkout*/ urls on WebSVN back when <a href="http://svn.kde.org" rel="noreferrer" target="_blank">svn.kde.org</a> was the primary repository and has continued throughout all of our Git repository hosting as well (and continues with /raw/ and /archive/ endpoints on Gitlab)<br>
><br>
> Actual Git clones should be used.<br>
><br>
<br>
Most of us are not going to do that, since our tooling is optimized<br>
around tarballs. When I say "fetching HEAD" I mean pulling from master<br>
using the tarball generator URL.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And the actual Git clones are slow and painful too anyway. Speaking as<br>
a GitLab admin myself, it's not hard to break GitLab with clones,<br>
especially big ones. :)<br></blockquote><div><br></div><div>There is quite a bit here to unpack...</div><div><br></div><div>To start with, I find it *highly* concerning that you are disregarding my request concerning the use of these endpoints simply because it does not fit with your tooling.</div><div>As mentioned earlier, to protect the long term sustainability of KDE.org infrastructure usage of the /archive/ and /raw/ endpoints of Gitlab from anything automated is strictly prohibited.<br></div><div><br></div><div>With respect to Git clones, I must disagree with you there. It takes under a minute to clone most Qt repositories from <a href="http://invent.kde.org">invent.kde.org</a> for me.</div><div>In my experience, we have little issue with cloning even with all of our CI nodes being busy and developers running kdesrc-build - there weren't even any issues during Akademy to my knowledge, and that would have been the busiest time for the system.</div><div><br></div><div> Regards,</div><div>Ben</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
<br>
--<br>
真実はいつも一つ！/ Always, there's only one truth!<br>
</blockquote></div></div>