tests: add OS_IMAGE_TYPE setting to allow for minimal tests #5682
Conversation
Allow setting CLOUD_INIT_OS_IMAGE_TYPE="mimimal" to support running the full integration test suite against Ubuntu minimal images. Required for SC-1750: Daily jenkins ubuntu minimal test runner for Ubuntu Focal, Jammy and Noble releases.
| # image-type lookup for daily_image and released_images. | ||
| # | ||
| # One of the following: | ||
| # - generic |
There was a problem hiding this comment.
Where do these names come from? I assume that this is a pycloudlib construct? Can we please include a pointer to wherever in pycloudlib this is documented to ease future maintenance of this?
There was a problem hiding this comment.
These come from the ImageType enum in pycloudlib. (pycloudlib.cloud.ImageType)
There was a problem hiding this comment.
Nice work on this @blackboxsw! I left a fix inline to address @holmanb's question.
Also, would you mind updating the integration docs to cover this new configuration option? Here's a patch to get you started (or if you think it is sufficient, just ship it 🫡)
diff --git a/doc/rtd/development/integration_tests.rst b/doc/rtd/development/integration_tests.rst
index aecb02244..a51657797 100644
--- a/doc/rtd/development/integration_tests.rst
+++ b/doc/rtd/development/integration_tests.rst
@@ -284,6 +284,31 @@ variable to be the desired image specification.
OS_IMAGE = 'jammy'
+To run integration tests on a specific type/family of image, modify the
+``OS_IMAGE_TYPE`` variable to be the desired image type. This comes from
+pycloudlib's ImageType enum, which can take the following values:
+
+- "generic"
+- "minimal"
+- "Pro"
+- "Pro FIPS"
+
+.. tab-set::
+
+ .. tab-item:: Inline environment variable
+
+ .. code-block:: bash
+
+ CLOUD_INIT_OS_IMAGE_TYPE='minimal' tox -e integration_tests
+
+ .. tab-item:: user_settings.py file
+
+ .. code-block:: python
+
+ OS_IMAGE_TYPE = 'minimal'
+
+Note: Not all clouds and images support all image types
+
Image setup
===========| # Determines unique image type or flavor to exercise if the cloud supports | ||
| # image-type lookup for daily_image and released_images. | ||
| # | ||
| # One of the following: |
There was a problem hiding this comment.
| # One of the following: | |
| # One of the following pycloudlib.cloud.ImageType values: |
This should sufficiently add context per brett's comment below
| # image-type lookup for daily_image and released_images. | ||
| # | ||
| # One of the following: | ||
| # - generic |
There was a problem hiding this comment.
These come from the ImageType enum in pycloudlib. (pycloudlib.cloud.ImageType)
| # - minimal | ||
| # - Pro | ||
| # - Pro FIPS | ||
| OS_IMAGE_TYPE = "generic" |
There was a problem hiding this comment.
We keep talking about additional OS support, and this one comes across as being Ubuntu-specific in a way that might encourage a bunch of OS-specific fields to proliferate across various OSes. We could try to encode this into OS_IMAGE, but I'm also wondering if it might be time for a new abstraction for all the various ways of specifying an image (e.g., differentiating amd64/arm is on the horizon too).
I think I'm ok with this now, but if we have to add another dimension to our image specification, I think we need a better solution.
There was a problem hiding this comment.
@TheRealFalcon: from the looks of other distribution vendors , there are similar alternative "offers" such as BYOS (bring your own subscription) images, HA and minimal images. I wonder if it is worth representing an optional "::offering" segment in
OS_IMAGE of the format
<image_id>[::<os>::<release>::<version>[::<offer-name>]]
This way we'd still have the ability to configure a known offer stream of images for Ubuntu, without bloating integration-settings.py options with yet another config param.
In the absence of offer-name, we'd assume generic, otherwise any string could be provided. From Ubuntu perspective, we could provide (generic|minimal|Pro|Pro FIPS). In the future, other vendors could provide BYOS, minimal, OSA(openshift app), etc.
For other distro support, I think we may have to rethink how we use pycloudlib.cloud.ImageType and maybe rename that OfferType to better align with how clouds label separate product images from vendors.
Proposed Commit Message
Additional Context
https://warthogs.atlassian.net/browse/SC-1750
Depends on canonical/pycloudlib#410
After the above this PR and the pyclluldlib PR merge, a serserver-jenkins-jobs matrix will be configured to run LXDContainer jobs against ubuntu-minimal:(focal, jammy, and noble)
Test Steps
Merge type