We aren't using this box and there's a use for it in the CentOS side, so
we are going to hand it over there. :)
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
It's overall simpler and more idempotent to just use a side repo
maintained outside of ansible than re-create one on each system
on each run of the plays.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This still doesn't mean that one project (= sandbox) can waste that
many workers, we still keep the per/sandbox limit on 35. This change
though drastically helps Packit which serves many users under a single
owner (but multiple sandboxes).
The pattern matching allows me to do tests in projects like:
$ copr-dev create measure-aws-powerful-c7i.8xlarge --chroot fedora-rawhide-x86_64
But the instance type needs to be selected manually in pools.yaml.
This will recycle VMs more quickly, after 90s of idling. This is giving
their assigned users smaller changes to re-take it. This though should
not be a problem nowadays since copr-backend is pretty optimal and each
"task dispatching cycle" takes less than 30s. If users have multiple
tasks to process, these tasks should still be happily dispatched within
the time-frame.
Rocky was added in the Anitya GUI, but does not have a mapping, so links
are not created for them which point to their corresponding sources on
their git forge.
The large instances discussed here
https://github.com/fedora-copr/copr/issues/2241
have large RAM memory segments, and no default disks. So we don't pay
attention to have additional volumes explicitly just for swap.
Recently (possibly with the new python in fedora 38), the updates-sync
logic that updates the 'latest' link for epel-release rpms has started
replacing it everytime it runs. Since this is every minute, it sometimes
results in people getting odd perm denied errors when they try and fetch
it as it's being removed or updated.
The problem seems to be that the script looks for all
epel-release*noarch* packages under a release tree and then links to the
x86_64 one. With all the other epel branches, x86_64 was the last one it
saw with the file glob, so everything was fine.
For some reason on epel7 now, it's seeing them in the following order:
/pub/epel/7/ppc64/Packages/e/epel-release-7-11.noarch.rpm
/pub/epel/7/x86_64/Packages/e/epel-release-7-14.noarch.rpm
/pub/epel/7/ppc64le/Packages/e/epel-release-7-14.noarch.rpm
/pub/epel/7/aarch64/Packages/e/epel-release-7-12.noarch.rpm
This means it sees the 'aarch64' one last and since it's not = to the
x86_64 one, it replaces it. Luckily it's hard coded to use the x86_64
one so the link is always the same, it's just never equal to the one
it's checking against.
I am not sure why this is happening only on epel7, but this PR just
sorts all the path's so that x86_64 is always 'last' and should match
up.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
