MirrorManager does not handle path changes in the mirror layout. Once a repository has been created in the database it cannot change the location. If the location has to change it has to be deleted or manually adapted to the new location.

MirrorManager does not handle path changes in the mirror layout. Once a repository has been created in the database it cannot change the location. If the location has to change it has to be deleted or manually adapted to the new location.

Once Kevin said that, it triggered a memory for me, too.

It seems probably safer/easier to remove the entries and have MirrorManager re-create them than to run a regexp_replace() against the tables. What do you think?

I don't think it makes sense to reconfigure MM to scan a different path or do manual database changes. The path is going to go back to the previous pattern (no os/ directory) in the near future (Q4, likely November). I see our choices not as the two put forth in the original description, but rather:

1. modify EPEL 10's nightly.sh script to create the same directory structure that bodhi did previously (and will again soon)
2. do nothing, accept that this is broken in the short term, and confirm it's resolved when we switch back to bodhi composes

I see our choices not as the two put forth in the original description, but rather:

1. modify EPEL 10's nightly.sh script to create the same directory structure that bodhi did previously (and will again soon)
2. do nothing, accept that this is broken in the short term, and confirm it's resolved when we switch back to bodhi composes

or 3. Tell people to override the values in epel.repo to set an explicit baseurl until this is addressed (and accepting that some will forget, and open additional issues sometime later when the mirror they selected goes MIA).

As an semi-interested party, I think doing nothing until sometime in November is a poor choice, but I have personally chosen option 3. for now (works-for-me).

We explicitly haven't launched EPEL 10 yet. It doesn't make sense to tell people to override the values in epel.repo when we haven't told anyone to start using the repo yet, much less provided them an epel.repo file. There is an epel.repo file in epel-release with the expected URLs for after we launch, but we haven't been giving out the URL to that RPM, and also haven't created the expected epel-release-latest-10.noarch.rpm symlink to it yet. Anyone who seeks out the epel-release RPM or the epel.repo file at this point should set their expectations accordingly. That's why I included this warning in the discussion thread and corresponding epel-devel email thread:

Quick note for anyone watching this thread, please keep in mind that some pieces of the infrastructure will continue to be in flux until the official launch.

I'm going to try to implement (1), but if I can't figure it out in time then we'll defacto be doing (2).

https://pagure.io/pungi-fedora/pull-request/1382

That PR is merged now, and I took care of the manually cleanup of the os directory on dl.fpo. The mirrormanager links are now working again, at least with the top 5 or so mirrors that are being returned for me that I checked. I imagine some mirrors will take a little bit longer to sync up the changes, but I think it's at a point now we can call this resolved.

Thanks!