/cc @lucarval

@cqi @lucarval what should we do with this ticket ? Does MTS need to be enable in prod ?

@sgallagh, @mohanboddu ^

ping?

What is expected of us?

ping again?

Anything we need to do here?

Otherwise I'd like to close this ticket

@cqi did you see the last two pings?

@sgallagh do you know something about this ticket?

@psabata @vmaljulin do you know the status of MTS in Fedora? Is that something that is still wanted/desired/needed?

Is there something for us to do here?

I don't know the current status as I'm not involved in these efforts anymore; perhaps @dmach would.

But I would say, it is still needed. MTS was meant to tag module builds into the right tags based on module runtime (not build time) dependencies, especially when using platform stream expansion, among other things.

I was under the impression we already had it, though.

I was under the impression we already had it, though.

Reading the first comment of the ticket, we do, but only in dry_run mode and apparently with some "fake" rules (which I would have no idea to update to what).

@pingou I'm now maintaining MTS which the factory team handed over to me. If MTS is going to be enabled in fedora-infra, the rules should be updated. But not sure who is/are going to do that.

If MTS is going to be enabled in fedora-infra

I guess this is the first question we need to answer :)

Is it going to?

the rules should be updated. But not sure who is/are going to do that

The application is deployed in our openshift cluster via ansible and its role can be found at: https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps/message-tagging-service I figure the information about the rule is in there.

Actually, if I read https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps/message-tagging-service/templates/app-config.py correctly, the rules are maintained at: https://pagure.io/mts-rules/raw/master/f/rules.yaml so outside of the ansible repo and only @cqi seems to have access to that project.

Actually, if I read https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps/message-tagging-service/templates/app-config.py correctly, the rules are maintained at: https://pagure.io/mts-rules/raw/master/f/rules.yaml so outside of the ansible repo and only @cqi seems to have access to that project.

My bad, the project mts-rules is only for staging, in production the rules are in: https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps/message-tagging-service/files/mts-rules.yml

If MTS is going to be enabled in fedora-infra

I guess this is the first question we need to answer :)

Is it going to?

I sure hope so; without it module tagging is simply wrong / broken.

If MTS is going to be enabled in fedora-infra

I guess this is the first question we need to answer :)

Is it going to?

I sure hope so; without it module tagging is simply wrong / broken.

Does this mean the current state is wrong / broken?
I mean the current rules in production have for id: "Example rule", so are
modules leaving without it so far "fine", or are things entirely broken and
nobody really complained ?

I've heard complain about the state of modularity in general, but not in a way
that I could (with my limited knowledge) relate the complain to MTS.

But I'm side-tracking the conversation, the original question was and still is:
is there anything the Fedora Infrastructure should do?

If MTS is going to be enabled in fedora-infra

I guess this is the first question we need to answer :)

Is it going to?

I sure hope so; without it module tagging is simply wrong / broken.

Does this mean the current state is wrong / broken?

It does, yes.

I mean the current rules in production have for id: "Example rule", so are
modules leaving without it so far "fine", or are things entirely broken and
nobody really complained ?

Some people have complained for a while, e.g. the Rust SIG folks, before abandoning modularity because it didn't work for them, with this being one of the reasons contributing to it.

I've heard complain about the state of modularity in general, but not in a way
that I could (with my limited knowledge) relate the complain to MTS.

This thing doesn't affect everyone, only modules that build in a specific (perfectly valid) way or serve a special, build-only purposes. We have implicit rules elsewhere (I think it's directly in MBS now) that tag modules based on their platform stream build dependency, regardless of what they indicate as their runtime platform(s). That's where MTS steps in and makes informed decisions about where each module build should be tagged. This also allows you to hide helper / bootstrap / buildroot-only / whatnot modules, not shipping them in the release tags. Think of glibc32 / glibc64 as a non-modular equivalent.

In more specific terms, Rust SIG wanted to build their statically linked packages against their always current and rich Rawhide set of building blocks, and then ship those binaries for all stable releases. In their case, due to the nature of those builds, that idea generally works.

I recall Java wanting to do something similar, just the other way around -- build once the oldest supported platform, ship those artifacts everywhere. I think the Flatpak build chain also wanted to take advantage of this somehow.

Neither is currently possible without MTS or human intervention as those builds land only in the tag you build against. If you want them elsewhere, they need to be manually tagged after each such build. And you need the right permissions, too.

But I'm side-tracking the conversation, the original question was and still is:
is there anything the Fedora Infrastructure should do?

Deploy and configure the server, and disable the current naïve mechanism.

But I'm side-tracking the conversation, the original question was and still is: is there anything the Fedora Infrastructure should do?

Deploy and configure the server, and disable the current naïve mechanism.

After adding myself to it so I can check its status, it looks like it is still up and running (which was indicated in the first comment). It can be found at: https://message-tagging-service.fedoraproject.org/
So someone who knows how to configure it and how to disable the current mechanism can proceed.

I doubt anyone in the Fedora infrastructure knows how to do this. We do not maintain MTS, simply provide resources for people to run it.

I'll note two things to the person who is going to look at MTS in the future:

• Looks like it's failing to download the rules currently as it looks for them in cgit (which we no longer have), so https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps/message-tagging-service/templates/app-config.py needs to be adjusted

• It runs on a F30 container, which we likely should upgrade to a more recent and actually maintained container :)

I hope @julian8628 can help with that.

The rules should be pretty simple (but, you know...):

• If the module has an explicit list of runtime dependencies on platform, tag it into tags representing those runtime platforms, e.g. platform: [f32, f33] would land in the f32-modular-updates-candidate and f33-modular-updates-candidate; most modules will depend on exactly one platform.
• If the module has a generic runtime dependency on platform: [], tag it into all supported releases, including Rawhide (but this should probably only happen if the build dependency stream matches f\d+, so we don't tag EPEL and ELN builds into Fedora... or should we? And vice versa?). This means the rules need to be kept up-to-date, ideally automatically.
• If the module is blacklisted, don't tag it anywhere.

I think that covers all the scenarios.

Thanks for the info @pingou @psabata
I will look into the service setup and rules

@julian8628 feel free to ping if you need any help, I can't help you with MTS but I can help you understand how things are setup in our openshift & so on.

@julian8628 if the rules change please open a new ticket for us to work through.