So this essentially blocks any access to koji. We did that for fedora branching because people kept ignoring that it was happening and doing builds in the middle of it and ending them up in weird states. ;(

This may be less of an issue with epel? Perhaps we don't do this at first and see how it goes. It's pretty disruptive.:(

gitolite is not used anymore... this can be dropped (and should be from the fedora one)

pkgs machines are weird auth wise. They don't allow shell logins except to root, so thats syadmin-main. ;(
However, I wonder... could we make this a playbooks/manual playbook we just run from batcave?

yeah, no epel issue here... unless you want to set some variables? They are handy for using in templates so you don't need to change the same '10.0' or 10.1' or whatever in a bunch of places.

Yeah, these next two things do not apply to epel

drop, doesn't apply to epel

hum I guess koschei is desired for each minor? I guess needs discussed...

So this essentially blocks any access to koji. We did that for fedora branching because people kept ignoring that it was happening and doing builds in the middle of it and ending them up in weird states. ;(

This may be less of an issue with epel? Perhaps we don't do this at first and see how it goes. It's pretty disruptive.:(

Honestly, I agree, but didn't want to decide on this before checking the impact on staging... but the process is a lot smaller than what it's being done on fedora, so it might just be ok I suppose :)

gitolite is not used anymore... this can be dropped (and should be from the fedora one)

pkgs machines are weird auth wise. They don't allow shell logins except to root, so thats syadmin-main. ;(
However, I wonder... could we make this a playbooks/manual playbook we just run from batcave?

If i'm not mistaken, this is the actual script

https://infrastructure.fedoraproject.org/infra/ansible/roles/distgit/files/mass-branching-git.py

Are you talking about building a playbook that runs it? or to add variables to track current EPEL versions and keep the state properly? I'm in to work on either of those options on a future iteration of this process :)

yeah, no epel issue here... unless you want to set some variables? They are handy for using in templates so you don't need to change the same '10.0' or 10.1' or whatever in a bunch of places.

I'll remove this for now then... might consider for future iterations

Yeah, these next two things do not apply to epel

removed :D

drop, doesn't apply to epel

removed :D

hum I guess koschei is desired for each minor? I guess needs discussed...

I don't have a strong opinion on this ... maybe we can keep it on the active minors?

and thank you a lot @kevin for all the feedback ^^

So this essentially blocks any access to koji. We did that for fedora branching because people kept ignoring that it was happening and doing builds in the middle of it and ending them up in weird states. ;(

This may be less of an issue with epel? Perhaps we don't do this at first and see how it goes. It's pretty disruptive.:(

Honestly, I agree, but didn't want to decide on this before checking the impact on staging... but the process is a lot smaller than what it's being done on fedora, so it might just be ok I suppose :)

Yeah, I don't think it's needed. If something causes it to be needed, we can change it next time? :)

gitolite is not used anymore... this can be dropped (and should be from the fedora one)

pkgs machines are weird auth wise. They don't allow shell logins except to root, so thats syadmin-main. ;(
However, I wonder... could we make this a playbooks/manual playbook we just run from batcave?

If i'm not mistaken, this is the actual script

https://infrastructure.fedoraproject.org/infra/ansible/roles/distgit/files/mass-branching-git.py

Are you talking about building a playbook that runs it? or to add variables to track current EPEL versions and keep the state properly? I'm in to work on either of those options on a future iteration of this process :)

Yeah, just a playbook in playbooks/manual/ thats manually run by someone at the right time.

Right now running that requires sysadmin-main, because you have to login as root to pkgs01 and run it.
If we move it to a playbook we can make it so anyone in sysadmin-releng could run it.
But yeah, can be a later iteration, and just get someone from sysadmin-main to run it for now.

yeah, no epel issue here... unless you want to set some variables? They are handy for using in templates so you don't need to change the same '10.0' or 10.1' or whatever in a bunch of places.

I'll remove this for now then... might consider for future iterations

Yeah, these next two things do not apply to epel

removed :D

drop, doesn't apply to epel

removed :D

hum I guess koschei is desired for each minor? I guess needs discussed...

I don't have a strong opinion on this ... maybe we can keep it on the active minors?

Well, it doesn't do a new release unless you add it.

https://koschei.fedoraproject.org/

it doesn't yet even have 10 (although there is a reqest to add it)

I'd say this can be deferred and added later.

and thank you a lot @kevin for all the feedback ^^

Happy to help! Thanks for working on it.

We can use epel_major for the remove-target command.

In order to construct the right grep here, we may want to restructure the attributes so we can use the minor version independently, something like el{epel_major}_{epel_minor_current}.

Lets add to this list:

• roles/koji_hub/templates/hub.conf.j2
• roles/robosignatory/templates/robosignatory.toml.j2

No changes to mirrormanager were necessary. We should however modify this section to verify that the mirrormanager regex scanner picked up the new directory.

curl 'https://mirrors.fedoraproject.org/metalink?arch=x86_64&repo=epel-{epel_current}'

LGTM