#7563 Request for resources: Message-Tagging-Service
Opened 3 months ago by cqi. Modified 5 days ago

Message-Tagging-Service, aka MTS, is an event-driven microservice to tag a module build triggered by MBS event mbs.build.state.change.

MTS basically listens on message bus for the MBS event mbs.build.state.change. Once a message is received, the module build represented by that message will be tested if it matches any predefined rules. Each rule definition has destination tag defined. If a rule matches the build, the destination tag will be applied to that build. Only module build in ready state is handled by MTS.

MTS has been containerized and deployed in production in internal, so we would like to deploy it to Openshift as well to serve module build tagging in Fedora.

EDIT:

MTS requires a keytab to log into Koji and permission to tag build by calling XMLRPC API tagBuild.

Phase I

Phase II

Phase III

  • SOP link:
  • Audit request:
  • Audit timeline:

Phase IV

  • Ansible playbooks:
  • Fully rebuilt from ansible:
  • Production goal:
  • Approved audit:

Metadata Update from @bowlofeggs:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: mbs, request-for-resources

3 months ago

I've heard from out-of-band sources that there are questions about what problems the MTS solves.

The most clear-cut one is this: a module that is built once and run on multiple releases. For example, let's consider the Golang case. Many Golang packages are statically-linked (as is the custom of that ecosystem), so they have few or no external dependencies. However, let's say that this module only currently builds for Fedora 30, because it requires Golang 1.12beta at build-time. Once built, there's nothing preventing it from running on Fedora 28 and 29, so we'd define its dependencies in the module metadata as:

dependencies:
  - buildrequires:
      platform: [f30]
    requires:
      platform: []

This translates to "Build against Fedora 30, run on any available platform". Now, however, we need some mechanism to ensure that the built module is tagged into each of the supported platforms, not just into the one against which it was built. Today, this is a manual process whereby the maintainer does a build and then pings release-engineering to tag it manually into the appropriate releases. The module tagging service will set up rules to have this happen automatically.

Makes sense to me, @sgallagh. We should make sure @rbarlow is aware of this thought process, since Bodhi would need to promote the same module build through multiple tag hierarchies for that to be useful. Initial tagging by MTS here would be the first step.

On Thu, 2019-02-14 at 21:15 +0000, Ralph Bean wrote:

Makes sense to me, @sgallagh. We should make sure @rbarlow is aware
of this thought process, since Bodhi would need to promote the same
module build through multiple tag hierarchies for that to be useful.=20
Initial tagging by MTS here would be the first step.

Note that my management chain has decided that doing this is not a
priority right now. It requires a significant backwards incompatible
change to Bodhi, and we already have other large initiatives in
progress right now.

The Bodhi change (that would make it possible to have one build be included in multiple updates for multiple releases) should not be dependency for thins RFR as MTS is useful even without Bodhi change.

I will sponsor this RFR. With that we can move to phase 2, in which you should start a thread on infrastructure mailing list. See RFR SOP for details what information you should post to the list.

Metadata Update from @mizdebsk:
- Issue assigned to mizdebsk

3 months ago

Ticket releng#8176 is created to ask for agreement on this proposal.

Just to confirm that I agree to be a Development and Maintainership contact.

ack on being listed under Development and Maintainership.

I believe that we are ready to move out of planning phase - all questions on infrastructure list have been answered and release engineering was in favour of running MTS service in Fedora.

In the next phase a SOP document will need to be created. Please open a pull request for infra-docs adding relevant SOP document.

I think that the RFR part about creating a development instance can be skipped as we generally don't set them up for OpenShift apps (as far as I know).

Since MTS is closely related to MBS, can we re-use sysadmin-mbs as group of people allowed to administer MTS? sysadmin-mbs group is already used for various modularity-related services besides MBS.

@puiterwijk Can we schedule a security audit for this service, as required by the RFR process?

Since MTS is closely related to MBS, can we re-use sysadmin-mbs as group of people allowed to administer MTS? sysadmin-mbs group is already used for various modularity-related services besides MBS.

Hi @mizdebsk , from where can I see the members of group sysadmin-mbs?

Since MTS is closely related to MBS, can we re-use sysadmin-mbs as group of people allowed to administer MTS? sysadmin-mbs group is already used for various modularity-related services besides MBS.

Hi @mizdebsk , from where can I see the members of group sysadmin-mbs?

https://admin.fedoraproject.org/accounts/group/view/sysadmin-mbs

Thanks. @mizdebsk , can you please also add lucarval and vmaljulin into group sysadmin-mbs? Then, let's re-use this group.

The SOP PR looks good to me - I don't have permission to merge it myself.

@jkaluza @mprahl @ralph : Do you agree with using sysadmin-mbs group for controlling who has access to running MTS playbook? If yes, can you add @lucarval and @vmaljulin to that group?

I believe we are ready to move to the next phase - creating staging instance in OpenShift. @cqi Please let me know if you need any help with that.

@mizdebsk So far, there is no security issue reported by puiterwijk. Does it mean MTS have passed the security audit? Or, do we need to get confirmation from him about that?

I believe we are ready to move to the next phase - creating staging instance in OpenShift. @cqi Please let me know if you need any help with that.

I think yes. @mizdebsk This is my first time to go through these steps to deploy a service into Fedora infra. I have no idea if I could have permission to create a stage instance, from where and how to create. Or, are you the right person to help to create the stage instance?

I learned from the SOP Staging Instance step, I need to write ansible role to deploy MTS, but I'm not sure once the stage instance is created, what resources will be available for me to run the ansible playbook and test the deployment, proper permissions to ssh into stage host and run playbook, stage hostname that I can ssh, or something else? Do I need to file another ticket separately to Fedora infra to request permissions?

@cqi, the reason for no security items reported is most likely that @puiterwijk is currently tasked with a lot of other items which management have rated as higher priority. I do not know when he will be able to get get to this, but @jperrin would be the one to contact on priorities.

On the second point, you will need to create a playbook and sysadmin-main will have to add it to the rbac-ansible rules for you to run. You are in sysadmin-mbs so we would put it in that role. Please open a separate ticket on that

@smooge Thanks for the info. With some guide from colleagues, I succeeded to clone the infra ansible repository. I saw there is patches sent to Fedora infra mailing list, just wanna confirm if that is the normal way to request review and merge for MTS?

Hi @kevin, I'm writing mts role and I need to put a URL of a rule file into configmap.yml. Is there already an existing repo containing a rule file? Do I need to file a ticket for creating such a repo and the initial rule file?

I think that for now you can store the rule file directly in ansible.git. If you want to store it in a separate repository then you can create it yourself, eg. on pagure.io

@cqi What is the progress here? Do you need any help with creating repository for MTS configuration? Or with anything else (Ansible playbook, OpenShift objects etc)?

Am I right in thinking this functionality will also facilitate build-only modules?

In the sense that I have a module that is intended only for building other modules and is not meant to ship to users. However right now if I build that module for rawhide it will ship to users because there is no bodhi gating, is that correct?

Right now, when you build a module on rawhide, MBS will tag it by itself with f31-modular-updates-candidate Koji tag. Since F31 doesn't use Bodhi yet, builds tagged there are auto-signed and moved to f31-modular tag, from where they are composed and delivered to users.

After deploying MTS, MBS will no longer tag modules anywhere - this will be responsibility of MTS. Unlike MBS, MTS has a configurable policy that can express what should be tagged where. It should be possible to configure MTS in a way that it will tag buildroot-only modules differently, so that they won't be moved to f31-modular.

Hey @cqi any status here? Anything we can help you with to move this forward?

Login to comment on this ticket.

Metadata