Well, I think there's some confusion here.

• fedmsg has python2 and python3 support. (ie, you can install whichever subpackages, configure and use it depending on if your app is python2/3)

• Many of our apps/services are indeed using the python2 version of fedmsg. However, most of these are running on rhel7 hosts. python2 is not being retired there and we shouldn't have to do so, we have prioritized things with our rhel7 using apps at the end of python3 porting for now.

• Our fedmsg/base role actually seems to do the right thing and installs the python3 version on fedora's.

• Our fedmsg/hub and probibly some of the other roles needs work, as they always install the python2 version, but that should be pretty easy to fix.

Finally, we are switching all this over to fedora-messaging (which I hope is python3 ready).

Adding @jcline and @abompard for any input.

I am happy to work on playbooks and make sure all the fedora hosts are moved to python3, but I am not clear on how this is affecting you or what else you need us to do.

Adding @adamwill - my understanding was that

https://pagure.io/fedora-qa/fedora_openqa

and

https://pagure.io/fedora-qa/autocloudreporter

are running on Fedora on Python 2 and the reason is only becasue fedmsg is somehow provisioned only for python 2. There's definitively some confusion here, as I have zero knowledge of how any of this is actually working (for me it's just black magic and pixie dust).

My motivation is a need to drop several packages from Fedora repos that I have been told not to drop because fedmsg in infra playbooks is running on python 2.

More context is in https://bugzilla.redhat.com/show_bug.cgi?id=1627234

Our fedmsg/hub and probibly some of the other roles needs work, as they always install the python2 version, but that should be pretty easy to fix.

The work necessary here would be to:

ensure "python3-fedmsg" is installed, and start fedmsg-hub-3.service instead of fedmsg-hub.service.

Assuming the consumer is Python 3 compatible that should be it. Do we know of any non-Python 3 consumers? I'm guessing we don't want to flip this on infra-wide, and instead do it service-by-service.

Currently fas which uses fedmsg to trigger password updates and such is on EL6.

The work necessary here would be to:
ensure "python3-fedmsg" is installed, and start fedmsg-hub-3.service instead of fedmsg-hub.service.
Assuming the consumer is Python 3 compatible that should be it. Do we know of any non-Python 3 consumers? I'm guessing we don't want to flip this on infra-wide, and instead do it service-by-service.

I think we should flip it on for say f29+ hosts?

Currently fas which uses fedmsg to trigger password updates and such is on EL6.

But we leave all the rhel7/rhel6 hosts on python2 for now, so that shouldn't be affected.

FWIW, I plan to declare to the world, strong and true, that Bodhi 3.11 is Python 3 compatible. That should be released "soonish" (3.10 is in staging, so I'm taking about the next next release). Bodhi runs on F27 for now, but I was also planning to upgrade it to F29 once it's released. So all that to say, I'm happy to be a guinea pig.

Taskotorn now also runs on Python 3 \o/

I wonder what can be done to get rid of python2-resultsdb_api and friends form Fedora.

As of yesterday, Bodhi is running on Python 3. It did have a few problems since it was deployed, so now I'm working on a 3.11.1 that should be more stable.

It was a lot more work than I anticipated to actually get it running, and quite a few problems were uncovered during testing (and sadly, 3 were uncovered only in production).

Anyways, I can't wait to drop Python 2 support next (Bodhi 4.0.0) and start using some of the juicy new Python 3 features.

I've moved openQA prod and staging to Python 3 fedmsg now.

I made a change to the ansible infra scripts which makes it relatively easy to have a system use fedmsg-hub-3 instead of fedmsg-hub: just add it to an inventory group with python34-fedmsg in its name (recommended way to do that: add the main group the system is in to the [python34-fedmsg:children] group in inventory). This currently only applies to the hub service - I didn't change the behaviour for any of the other fedmsg services - but it would be easy to extend.

@kevin before converting a large number of hosts wholesale, you'd have to make sure they also have the Python 3 versions of the appropriate consumers installed (that's the necessary additional step that's missing from @jcline 's comment).

Note that EPEL7 is moving to python36 (update is in testing), so we may need to rename things to python36?

At this point perhaps it's better to move things to fedora-messaging rather than move from fedmsg-2 to fedmsg-3?

Is there some way we can generate a list and just switch them after freeze and then see what breaks?

You can't really "just switch" things, either to Python 3 or fedora-messaging. Even "just switching" to Python 3 requires making sure the fedmsg consumer (or whatever) runs under Python 3. Switching to fedora-messaging is a significant code change, you can't just flip a button somewhere. (Sadly.) People gonna have to rewrite stuff.

I think at this point we want to move all fedmsg stuff to fedora-messaging... I think we can track that in another place, so closing this for now.