Message Tagging Service SOP

Contact Information

Owner

Factory2 Team, Fedora QA Team, Infrastructure Team

Contact

#fedora-qa, #fedora-admin

Persons

cqi, lucarval, vmaljulin

Location

Phoenix

Servers

  • In OpenShift.

Purpose

Tag module build

Description

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

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 for now.

Observing Behavior

Login to os-master01.phx2.fedoraproject.org as root (or, authenticate remotely with openshift using oc login https://os.fedoraproject.org), and run:

oc project mts
oc status -v
oc logs -f dc/mts

Database

MTS does not use database.

Configuration

Please do remember to increase MTS_CONFIG_VERSION so that Openshift creates a new pod after running the playbook.

Deployment

You can roll out configuration changes by changing the files in roles/openshift-apps/message-tagging-service/ and running the playbooks/openshift-apps/message-tagging-service.yml playbook.

Stage

MTS docker image is built automatically and pushed to upstream quay.io. By default, tag latest is applied to a fresh image. Tag stg is applied to image, then run the playbook playbooks/openshift-apps/message-tagging-service.yml with environment staging.

Prod

If everything works well, apply tag prod to docker image in quay.io, then, run the playbook with environment prod.

Update Rules

Rules file is managed along side the playbook role in same repository.

For detailed information of rules format, please refer to documentation under Modularity.

Troubleshooting

In case of problems with MTS, check the logs:

oc logs -f dc/mts