Project

General

Profile

Actions

action #124385

closed

test and release the rmt containers

Added by msmeissn over 1 year ago. Updated 9 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
2023-02-13
Due date:
% Done:

0%

Estimated time:

Description

Part of the BCI space are the rmt containers.

rmt-helm

  • helm chart. Bruno Leon maintainer rmt-server-image
  • images, SCC team responsible.

Contact: Natnael Getahun

Refresh strategy for the images would be the usual RPM or description changed.

helm chart could be handled separately, likely needs some kubernetes setup if we want to test it.

Weblinks

Acceptance criteria


Files

Actions #1

Updated by jlausuch over 1 year ago

  • Project changed from openQA Tests to Containers
  • Status changed from New to Workable
Actions #3

Updated by ngetahun over 1 year ago

@jlausuch I see that the PR is merged, what are the next steps?

Actions #4

Updated by jlausuch over 1 year ago

Ok, there are 2 main blockers:

1) The helm chart is pulling the images from registry.suse.com:
https://github.com/SUSE/helm-charts/blob/main/rmt-helm/values.yaml
So, this is not the images we want to test.
The images we want to test are in IBS before they are released.

So, you would need to do some string replacement in that file to use these images instead:
registry.suse.de/suse/sle-15-sp4/update/cr/totest/images/suse/rmt-mariadb:latest
registry.suse.de/suse/sle-15-sp4/update/cr/totest/images/suse/rmt-mariadb-client:latest
registry.suse.de/suse/sle-15-sp4/update/cr/totest/images/suse/rmt-nginx:latest
registry.suse.de/suse/sle-15-sp4/update/cr/totest/images/suse/rmt-server:latest

I guess that's feasible to do it at test execution time (in openQA).

2) Besides this, the problem with these containers is that there are several containers which are depending on each other:

Our container bot can watch for image updates in individual images, not in batch of images. So, if we take rmt-helm as the reference image, we would trigger the tests only when this image gets an update, and if tests are green, the bot would release ONLY rmt-helm image...

@msmeissn I am not sure how to solve this second issue. Any thoughts?

Actions #5

Updated by msmeissn over 1 year ago

The helm chart uses version tags

registry.suse.com/suse/rmt-mariadb:10.5
registry.suse.com/suse/rmt-mariadb-client:10.5
registry.suse.com/suse/rmt-server:2.8
registry.suse.com/bci/bci-micro:15.3
registry.suse.com/suse/rmt-nginx:1.19

and the tags do not change except when the sources of the helm chart are touched.

so lets try:

containers:

  1. Have workflows for each rmt container, usual change detection:

In the workflow, use the helm chart from CR (not the released helm chart) but modified to point ToTest :latest containers and wrap testing around that.

If it works, release respective container.

This mapping to :latest allows version upgrades of e.g. rmt-server container or mariadb.... The containers will be released here, already tested but not yet picked up outside.

  1. Have a workflow for the helm chart on change detection

Use helm chart from ToTest, do not modify it ( so use containers from official registry.suse.com )

If it works, release helm chart.

This should work as the usual workflow will be:

  • we update the container sources first
  • we update helm chart sources second
Actions #6

Updated by jlausuch 11 months ago

Meeting with @ngetahun and @ph03nix:

  • the container-release-bot has the limitation that it treats the images independently from each other. It can't test and release a batch of images at the same time (atomically).
  • This is ok, because the only crucial image that needs testing is the rmt-server-image.
  • For now we will enable the pipeline for the rmt-server-image image only. The other images don't receive a lot of updates anyway. The most important image that should be tested and updated automatically is the server.
  • In the future, we can add additional tests for other images (e.g. helm chart) if we need automatic updates for those as well. The tests coverage doesn't need to be the same as for the server, but that's up to the implementer.

AP's:

Open Questions

  • How are tags handled? Will latest will be updated pointing to the latest image? How is build/version numbering happening in registry.suse.com?
  • Do we want to test RMT image based on 15-SP5 or 15-SP4? Or both?
Actions #7

Updated by ph03nix 11 months ago

  • Status changed from Workable to In Progress
  • Assignee set to ph03nix
Actions #8

Updated by ph03nix 11 months ago

Meeting with Natnael - We concluded that from here he will write a simple test proposal (in bash/pseudocode) and based on this proposal we can evaluate how to proceed.

ATM we have the blocker, that Natnael is blocked my missing openQA knowledge and we are blocked due to missing helm knowledge. A basic test setup might help us to resolve this blocker and decide, how to advance.

Actions #9

Updated by ph03nix 11 months ago

Here's the test that Natnael came up with. We need to create a openQA test for it or see if https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16313 can be used

export REPO="https://github.com/SUSE/helm-charts/archive/refs/heads/main.zip"
wget --quiet --no-check-certificate $REPO
unzip main.zip
export RMT_HELM_VALUES="https://gitlab.suse.de/QA-APAC-I/testing/-/raw/master/data/rmtcontainer/myvalue.yaml"
wget --no-check-certificate $RMT_HELM_VALUES

helm install rmt ./helm-charts-main/rmt-helm -f myvalue.yaml
helm list
kubectl get pods | grep "rmt" # Should see 3 pods running

The test code looks rather simple. Maybe it's ok if we do it, since we are anyways having some experience with helm and k3s.

Actions #10

Updated by ph03nix 11 months ago

  • Description updated (diff)
Actions #11

Updated by rbranco 11 months ago

  • Assignee changed from ph03nix to rbranco
Actions #13

Updated by rbranco 11 months ago

  • Assignee changed from ph03nix to rbranco
Actions #14

Updated by ph03nix 11 months ago

  • Description updated (diff)
Actions #15

Updated by ph03nix 11 months ago

  • Description updated (diff)
Actions #18

Updated by ph03nix 11 months ago

The rmt-nginx container will be replaces by suse/nginx container image. This should not affect our testing however, as we should be using the provided helm chart, which should be updated as well.

Actions #19

Updated by ph03nix 11 months ago

Meeting with Ricardo and Natnael

RMT image location in IBS: https://build.suse.de/package/show/SUSE:SLE-15-SP5:Update:CR/rmt-server-image

I can't pull the RMT CR image from registry.suse.de/suse/sle-15-sp5/update/cr/totest/images/suse/rmt-server - this needs to be done Natnael.

Next steps

  • Natnael will ensure the CR images get published to registry.suse.de
  • We need to inject the testing registry link into the helm chart (e.g. using the --set app.image.repository= CLI option?)
  • Ensure openQA test runs with the testing registry are working
  • Integrate the testing openQA run into the container-release-bot
Actions #20

Updated by ph03nix 11 months ago

The container location is in registry.suse.de/suse/sle-15-sp5/update/cr/totest/images/suse/rmt-server:latest

Actions #22

Updated by rbranco 10 months ago

This PR tests all 4 components, not just rmt-server:

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17697

Actions #26

Updated by rbranco 10 months ago

  • Status changed from In Progress to Feedback
Actions #27

Updated by rbranco 10 months ago

It's working now:
https://openqa.suse.de/tests/overview?distri=sle&version=15-SP5&build=9.46_rmt-server-image&groupid=445

I need to remove unneeded architectures and distros where it's failing.

Actions #30

Updated by rbranco 10 months ago

Hopefully the final PR to skip running on k8s as runtime:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17790

Actions #31

Updated by rbranco 9 months ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF