I'd like to see this get done sooner rather than later so we can have all the Fedora/CentOS infra pagure instances on EL8 and Python 3 based so that I can proceed with dropping Python 2 support from Pagure upstream and start cleaning up the codebase for the 6.0 release.

I'm happy to help with making that happen as much as I can.

Also, the new directory listing API would be super useful.

Folks I think we should close this ticket, and create a new ticket on https://pagure.io/fedora-infrastructure/issues

There's an equivalent ticket for fedora-infrastructure already: https://pagure.io/fedora-infrastructure/issue/8786

@ngompa aha great, closing here. Its best to follow up in https://pagure.io/fedora-infrastructure/issue/8786 in that case.

@ngompa is raising an interesting question: which pagure was this ticket about? pagure.io or git.centos.org?

If the former, then https://pagure.io/fedora-infrastructure/issue/8786 is the right ticket to track this, if the later, then I guess this ticket is valid. Isn't it?

This ticket is about git.centos.org. I directed @zx2c4 to file a ticket here specifically about that.

@ngompa aha great, closing here. Its best to follow up in https://pagure.io/fedora-infrastructure/issue/8786 in that case.

Even though this is about CentOS, not Fedora?

Entering the thread : what are the technical and/or security reasons why we'd need to update our pagure instances in the centos infra ? Open to the discussion but as we know, migration to gitlab (I heard today) is "still a thing" so probably not upgrading for the sake of upgrading if no blocking factor (like broken instance or security issue). All comments are welcome :)

Entering the thread : what are the technical and/or security reasons why we'd need to update our pagure instances in the centos infra ? Open to the discussion but as we know, migration to gitlab (I heard today) is "still a thing" so probably not upgrading for the sake of upgrading if no blocking factor (like broken instance or security issue). All comments are welcome :)

Fetching large files is excruciatingly slow and makes it impossible to efficiently script file retrieval for version checking. This was fixed in newer versions of Pagure, according to @ngompa . As well, the directory listing API allows scripts to avoid downloading tons of extra data.

@zx2c4 : can you come with some examples ? as blobs aren't in git/pagure itself but in lookaside, so if you can come with some examples so that we can reproduce , that would be great.
I'll also mark this to be reviewed with @pingou during daily review and see where/when/how to prioritize this request

@zx2c4 : can you come with some examples ? as blobs aren't in git/pagure itself but in lookaside, so if you can come with some examples so that we can reproduce , that would be great.

Sure. Try loading: https://git.centos.org/rpms/kernel/raw/c7-sig-centosplus-kernel/f/SOURCES/centos-linux-3.10-wireguard.patch You'll notice it takes 45 seconds before it even delivers the first byte.

@pingou : as sustaining team lead : do you vote for this to enter backlog and so proceed ? I can test ansible rollout easily on git.dev.centos.org and then git.stg.centos.org (to let other teams test that it works) and then also deploy the same way on git.centos.org

We probably want to schedule this with upgrading to Pagure 5.12 and maybe also get this onto EL8 at the same time. Pagure 5.12 will contain an enhancement specifically for @zx2c4's issue: https://pagure.io/pagure/c/1163ed9aec1eb66e03d9683f3fbde90271413a24

@ngompa : well, infra is still centos 7 and if management/Red Hat decided to migrate git.centos.org to gitlab, I don't think we'll reinstall/migrate to centos 8 for git.centos.org.
Updating pagure on existing infra is one thing (and again, asking about priorities to be set and so if @pingou says "let's do it" we can do it, otherwise, still in backlog (and discussion to be triaged at some point)

Hmm, then probably cchardet will need to be packaged for EL7... :cry: