I have removed the build targets to ensure no more EPEL 7 builds are created.

$ koji remove-target epel7
$ koji remove-target epel7-candidate

I've done the following:

• Archived epel7 in bodhi
• removed epel7-infra targets and el7-openjdk
• Deleted the koschei epel7 collection (well, started it)
• Created a PR to remove stuff in ansible:
  https://pagure.io/fedora-infra/ansible/pull-request/2114
  (reviews welcome!)
• removed epel7 (and 6) from block_retired.py. This script was trying to untag/block all epel7 builds and causing koji to be unresponsive from time to time. It untagged a bunch of builds, we will need to decide if we want to tag them back in or untag the rest or just don't care.
• removed a bunch of old external repos, including the epel7 ones.

Do you have the necessary powers to EOL epel7 bugzillas?

The EPEL sig was going to look at someone doing that.

I did however just change it to disallow new bugs at least.

It untagged a bunch of builds, we will need to decide if we want to tag them back in or untag the rest or just don't care.

I got an email about a bunch of my epel7 builds being unreferenced and marked for deletion. I assume this was from having the epel7 tag removed. We should probably retag these before the grace period runs out.

I've started a slow task to tag these back in.

It should hopefully finish before anything moves to the trashcan.

This finished a while back.

I think we are all done here.

If there's anything else anyone can think of, feel free to re-open. ;)

One last thing, we need to archive the repo content and leave a README file in it's place similar to the one for EPEL 6. Hopefully mirrormanager will pick up the new directories and return archive mirrors for EPEL 7 requests, but we should verify this after the archiving takes place.

I've synced the content to archive and am updating the fullfilelist

@abompard @adrian In the past we would run 'mm2_move-to-archive' utility script to move the database pointers. In this new openshift mirrormanager, where/how do we do that now?
:)

I don't know where to run the script. but I wanted to mention that the old script always had to be adapted to work with any category but Fedora Linux. So even if you find a place to run the script it probably needs to be changed. On the old system I had one script for Fedora Linux and another copy for the secondary arches category.

Fair enough.

FWIW, koschei handles this by having a -admin pod. You can then oc rsh into it and run whatever admin/utility scripts you need and it's using the same image and has the db/config all setup.
I would think a similar pattern would work for mirrormanager in openshift, but would defer to those doing the work.

In OpenShift it's always possible to run oc -n mirrormanager debug dc/frontend, it'll give you a pod with everything mounted properly and all the scripts available. But if we want something more automated, we can prepare OpenShift Jobs that can be triggered by a manual playbook run.

I'm happy to help set those up if it's the path we want to take. I can also adjust the mm2_move-to-archive script if necessary. I see that it accepts --originalCategory and --archiveCategory options, so maybe that's sufficient?

@adrian , do you remember which adjustments were necessary?

@adrian , do you remember which adjustments were necessary?

The path is hardcoded to pub/fedora or something like this and that needs to be changed (better a parameter, or pulled from the database).

If the old mm-backend01 is still somewhere you should be able to see the script for secondary in /root.

We do have it. I have copied those to batcave01:/root/mm-backend01.iad2.fedoraproject.org/

ls -la mm-backend01.iad2.fedoraproject.org/
total 28
drwxr-xr-x.  2 root root   102 Jul 26 20:03 .
dr-xr-x---. 79 root root 12288 Jul 26 20:03 ..
-rwxr-xr-x.  1 root root  3273 Jul 26 20:03 mm2_move-to-archive
-rwxr-xr-x.  1 root root  3273 Jul 26 20:03 mm2_move-to-archive.epel
-rwxr-xr-x.  1 root root  3285 Jul 26 20:03 mm2_move-to-archive.secondary

OK I tried running the script on staging and it's complaining that it does not find:
/srv/pub/archive/epel/testing/7
Indeed there are only directories in the form of 7.YEAR-MONTH-DAY or 7.MINOR, but not just 7. Is it normal?

Has testing actually been moved to the archive?

Because https://dl.fedoraproject.org/pub/archive/epel/testing/ seems missing things from https://dl.fedoraproject.org/pub/epel/testing/

I guess someone needs to just copy it.

Yeah, my bad I guess. It's copied now.

Thanks, the staging script now completes without error.
Before I make the actual change, I have a question: I find it a little bit surprising that the move-to-archive script takes a regular expression as argument to find the directories to move. It looks like this regexp is supposed to be something like /7/, /38/, etc, so, a version.
What if I change the script to take a distro name and version instead? I think that would be less error-prone (I'm usually a bit cautious about regexes)
Are there use cases where we want to have a regexp that is not a distro version? Would you know that @adrian ?

I don't know why it uses a regex. It has been that way forever and I never used anything fancy there. I always used exactly one version. From my point of view you can change it in any way you want. It was always a hack as it required three different scripts with hardcoded paths. I think any change to the script will be an improvement.

Alright, this command should do the trick:

ansible-playbook -v /srv/web/infra/ansible/playbooks/manual/mirrormanager-move-to-archive.yml --extra-vars="product='EPEL' version='7'"

Should I run it or does someone from releng want to do it?

Why don't you go ahead and run it? If it fails you can debug it without a middle person. ;)

OK done!

Looks like it worked to me:

carl ~ 
❯ curl -s 'https://mirrors.fedoraproject.org/metalink?arch=x86_64&repo=epel-7' | grep url
    <url protocol="http" type="http" location="US" preference="100">http://mirror.math.princeton.edu/pub/fedora-archive/epel/7/x86_64/repodata/repomd.xml</url>
    <url protocol="rsync" type="rsync" location="US" preference="100">rsync://mirror.math.princeton.edu/pub/fedora-archive/epel/7/x86_64/repodata/repomd.xml</url>
    <url protocol="https" type="https" location="US" preference="99">https://d2lzkl7pfhq30w.cloudfront.net/pub/archive/epel/7/x86_64/repodata/repomd.xml</url>
    <url protocol="rsync" type="rsync" location="US" preference="98">rsync://pubmirror1.math.uh.edu/fedora-archive/epel/7/x86_64/repodata/repomd.xml</url>
...(continues)

Next we need to replace the contents at https://dl.fedoraproject.org/pub/epel/7/ with a README file, and then I think this issue can be closed.

Done that and epel/testing/7 as well.

Shall we close this out now?

One last thing I just noticed, the README references IRC, and freenode at that. That was two networks ago. :grinning: We could update it to refer to the matrix channel instead, as that's our default now. Or we can just remove the chat reference entirely. Or reference the issue tracker. There are a few ways to handle it, I don't care too much, but once you're happy with the README file I think we can close this issue.

So, I just copied the readme... how about we close this and open a new ticket to update all the readmes (since they should all be the same)