Skip to content

How to promote the Salt packages

Jump to bottom
Yeray Gutiérrez Cedrés edited this page Oct 2, 2024 · 33 revisions

Introduction

We have automated the process to "promote" our testing changes for Salt into our "stable" projects. We are using Jenkins pipelines for doing these tasks:

Salt RPM Package Promotion Pipeline

This promotion pipeline is used to “promote” the OBS package from the products:testing project to the products project. It runs in Jenkins and is manually triggered by a member of the Ion Squad. The products project is linked to projects in IBS that are used for releasing SUSE Manager. For this reason we have a separate OBS project that receives submit requests.

This Jenkins pipeline is defined in openSUSE/salt-package-promote-obs. If you want to learn more about the pipeline in detail, take a look at the Salt Promotion Interals page.

Promotion Checklist

The products:testing testsuite must be green and the diff between the source and destination projects should be correct and as expected.

Your check-list for the diffs:

  • all new changelog entries are placed on top of the current ones
  • all new changelog entries you've added are there
  • all new patches you've added are there
  • all patches you've removed are also removed
  • nothing else is happening that you didn't do (gets removed or added)
# Example of how to show changes that are going to be promoted

osc rdiff systemsmanagement:saltstack:products salt systemsmanagement:saltstack:products:testing
osc rdiff systemsmanagement:saltstack:products py26-compat-salt systemsmanagement:saltstack:products:testing
osc rdiff systemsmanagement:saltstack:products py26-compat-tornado systemsmanagement:saltstack:products:testing
osc rdiff systemsmanagement:saltstack:products py26-compat-msgpack-python systemsmanagement:saltstack:products:testing
osc rdiff systemsmanagement:saltstack:products py27-compat-salt systemsmanagement:saltstack:products:testing
osc rdiff systemsmanagement:saltstack:products:old salt systemsmanagement:saltstack:products:old:testing

If the results from the osc rdiff are looking good, then we can promote the packages.

How to run the Promotion Pipeline

Running the pipeline needs access to SUSE’s Jenkins. Log in with the SUSE Manager team credentials and navigate to Dashboard > manager-salt-package-promote-pipeline.

Parameters

  • salt_version: The Salt version that is currently used in products and products:testing.
  • mu_version: The Maintenance Update that the newly promoted version will be released in.

This pipeline is taking care of:

  • Promote necessary packages from products:testing to products
  • Promote necessary packages from products:old:testing to products:old
  • Run services on products:debian/salt to refresh the Debian package.
  • Run services for the Ubuntu (16.04 & 18.04) client tools at Uyuni:Master
  • Run services for the Ubuntu (16.04 & 18.04) client tools at Devel:Galaxy:Manager:4.0
  • Run services for the Ubuntu (16.04 & 18.04) client tools at Devel:Galaxy:Manager:Head

Salt Bundle (venv-salt-minion) Promotion Pipeline

This other promotion pipeline is used to “promote” the Salt Bundle OBS package (venv-salt-minion), as well as all the necessary Salt Bundle dependencies (saltbundlepy-* packages) from the systemsmanagement:saltstack:bundle:testing project to the systemsmanagement:saltstack:bundle project.

It also takes care of promoting the packages from the different client tools subprojects as well as the debbuild subproject:

  • systemsmanagement:saltstack:bundle:testing:AlmaLinux8
  • systemsmanagement:saltstack:bundle:testing:CentOS7
  • systemsmanagement:saltstack:bundle:testing:CentOS8
  • systemsmanagement:saltstack:bundle:testing:Debian10
  • systemsmanagement:saltstack:bundle:testing:Debian11
  • systemsmanagement:saltstack:bundle:testing:Debian9
  • systemsmanagement:saltstack:bundle:testing:Fedora33
  • systemsmanagement:saltstack:bundle:testing:Fedora34
  • systemsmanagement:saltstack:bundle:testing:Fedora35
  • systemsmanagement:saltstack:bundle:testing:Raspbian10
  • systemsmanagement:saltstack:bundle:testing:Raspbian9
  • systemsmanagement:saltstack:bundle:testing:SLE12
  • systemsmanagement:saltstack:bundle:testing:SLE15
  • systemsmanagement:saltstack:bundle:testing:Ubuntu1804
  • systemsmanagement:saltstack:bundle:testing:Ubuntu2004
  • systemsmanagement:saltstack:bundle:testing:debbuild

It runs in Jenkins and is manually triggered by a member of the Ion Squad.

This Jenkins pipeline is defined in openSUSE/salt-package-promote-obs.

NOTE: Please keep in mind this pipeline does not run automatically when running the other pipeline for the Salt RPM package, we need to run this explicitely.

Adding new dependencies for Salt

During a version bump, there might be new dependencies for Salt for this new version. It is important that we follow the next steps if there are new dependencies:

  • Make sure new dependencies are included in the Salt projects in OBS, and also inside Salt Bundle projects (bundle:next / bundle:testing).
  • Salt Bundle: Make sure the new "saltbundlepy-xxxx" package is added to "include-rpm" and "include-deb" files for the "venv-salt-minion" package.
  • Make sure SUMA and Uyuni RelEngs are aware of the new dependencies so they can be added to IBS and also to the corresponding channel definitions.
  • For classic Salt package: make sure the new dependencies are included in the bootstrap repository definition for the different OS (if applies): https://github.com/uyuni-project/uyuni/blob/master/susemanager/src/mgr_bootstrap_data.py

Releasing Salt in SLE / ALP

Once the packages are promoted to products, our SUSE Manager Release Engineer is taking care of creating the necessary Maintenance Requests (MRs) against SUSE Maintenance as part of the tasks for the next Maintenance Update (MU) for some of the release target codestreams, but not for all of them.

The Salt Maintainers needs to take care of creating the MRs in IBS for the following codestreams only at the time they get pinged by our Release Engineer at the time of preparing the MU submissions. All submissions need to include a jira id, which we get from our release engineers.

Remember to follow SUSE's factory-first policy and make sure all changes have been submitted to openSUSE:Factory first!

  • SUSE:SLE-15-SP2:Update
  • SUSE:SLE-15-SP3:Update
  • SUSE:SLE-15-SP4:Update
  • SUSE:SLE-15-SP5:Update
  • SUSE:ALP:Source:Standard:1.0 (normal SR)
  • SUSE:SLFO:Main (normal SR)

In order to do that, we Salt Maintainers, need to do the following for each codestream:

  1. Create a branch of the target codestream in IBS (e.g. iosc branch -M SUSE:SLE-15-SP2:Update salt, no -M neither for ALP nor for SLFO).
  2. Change "_service" file and adjust revision to the corresponding MU branch. Like MU-5.0.2. (to avoid getting patches that might be already pushed to testing) (e.g. sed -i 's,MU/5.0.1,MU/5.0.2,' _service)
  3. Run disabled services: iosc service disabledrun.
  4. Add the new patches and review the generated changelog entry. The number of changelog lines should correspond to the number of patches you're adding (osc status | grep ".patch" | wc -l).
  5. Commit the changes, e.g. iosc ci -m "prepare for release".
  6. Create MR with iosc mr -m '<jira id>' (iosc sr for ALP and for SLFO).

Happy promoting! 😉

Clone this wiki locally