The New Hotness

the-new-hotness is a fedora messaging consumer that subscribes to release-monitoring.org fedora messaging notifications to determine when a package in Fedora should be updated. For more details on the-new-hotness, consult the project documentation.

Contact Information

Owner

Fedora Infrastructure Team

Contact

#fedora-admin #fedora-apps

Persons

zlopez

Location

os.fedoraproject.org

Purpose

File issues when upstream projects release new versions of a package

Hosts

The current deployment is made up of the-new-hotness OpenShift namespace.

the-new-hotness

This OpenShift namespace runs following pods:

  • A fedora messaging consumer

This OpenShift project relies on:

  • Anitya as message publisher

  • Fedora messaging RabbitMQ hub for consuming messages

  • Koji for scratch builds

  • Bugzilla for issue reporting

Releasing

The release process is described in the-new-hotness documentation.

Deploying

Staging deployment of the-new-hotness is deployed in staging OpenShift.

To deploy staging instance of the-new-hotness you need to push changes to staging branch on the-new-hotness GitHub. GitHub webhook will then automatically deploy a new version of the-new-hotness on staging.

Production deployment of the-new-hotness is deployed in production OpenShift.

To deploy production instance of the-new-hotness you need to push changes to production branch on the-new-hotness GitHub. GitHub webhook will then automatically deploy a new version of the-new-hotness on production.

Configuration

To deploy the new configuration, you need ssh access to batcave01.iad2.fedoraproject.org and permissions to run the Ansible playbook.

All the following commands should be run from batcave01.

First, ensure there are no configuration changes required for the new update. If there are, update the Ansible anitya role(s) and optionally run the playbook:

$ sudo rbac-playbook openshift-apps/the-new-hotness.yml

The configuration changes could be limited to staging only using:

$ sudo rbac-playbook openshift-apps/the-new-hotness.yml -l staging

This is recommended for testing new configuration changes.

Upgrading

Staging

To deploy new version of the-new-hotness you need to push changes to staging branch on the-new-hotness GitHub. GitHub webhook will then automatically deploy a new version of the-new-hotness on staging.

Production

To deploy new version of the-new-hotness you need to push changes to production branch on the-new-hotness GitHub. GitHub webhook will then automatically deploy a new version of the-new-hotness on production.

Congratulations! The new version should now be deployed.

Monitoring Activity

It can be nice to check up on the-new-hotness to make sure its behaving correctly. You can see all the Bugzilla activity using the user activity query (staging uses bugzilla.stage.redhat.com) and querying for the [email protected] user.

You can also view all the Koji tasks dispatched by the-new-hotness. For example, you can see the failed tasks it has created.

To monitor the pods of the-new-hotness you can connect to Fedora infra OpenShift and look at the state of pods.

For staging look at the the-new-hotness namespace in staging OpenShift instance.

For production look at the the-new-hotness namespace in production OpenShift instance.

Want to help? Learn how to contribute to Fedora Docs ›