Bug 2161664

Hi!

This is already supported, but I'm afraid that we forgot to document it in the RHEL documentation.

See the upstream documentation for now: https://www.osbuild.org/guides/blueprint-reference/blueprint-reference.html#distribution-selection-with-blueprints
The blueprint has a `distribution` field that can be used to build a different minor version. If you want e.g. RHEL 8.4, just use `distro = "rhel-84".
`composer-cli distros list` can be used for listing all distributions that composer can build.
Note that we intentionally limit the list to just distributions that were released earlier than the host's distribution. You can for example build RHEL 9.1 and RHEL 8.7 on RHEL 9.1, but you can only build RHEL 8.7 (and older) on RHEL 8.7.

Can you please verify this with the customer and report back if it works for them? Thanks!

@elpereir Can you double-check that the RHEL's documentation indeed doesn't mention the `distro` option in blueprints? I might be just blind. If it's indeed not there, let's work together on adding it, it's very useful to lots of our customers.

(In reply to Ondřej Budai from comment #2)
> The blueprint has a `distribution` field

I meant `distro`, sorry!

I tried using the distro flag but I'm still getting 9.1 content.

[root@r9 ~]# composer-cli blueprints depsolve test  | grep kernel
    kernel-modules-5.14.0-162.6.1.el9_1.x86_64
    kernel-core-5.14.0-162.6.1.el9_1.x86_64
    kernel-5.14.0-162.6.1.el9_1.x86_64

[root@r9 ~]# cat test
name = "test"
description = "A relatively blank blueprint"
version = "0.0.1"
modules = []
groups = []
distro = "rhel-90"


Looking at the 90.json file, we have a releasever of 9 which means the latest and greatest, not 9.0

[root@r9 ~]# grep url.*x86_64 /usr/share/osbuild-composer/repositories/rhel-90.json
      "baseurl": "https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os",
      "baseurl": "https://cdn.redhat.com/content/dist/rhel9/9/x86_64/appstream/os",
      "baseurl": "https://packages.cloud.google.com/yum/repos/google-compute-engine-el9-x86_64-stable",
      "baseurl": "https://packages.cloud.google.com/yum/repos/cloud-sdk-el9-x86_64",

So I made a /etc/ file to override this:

# grep rhel9/9.*x86_64 /etc/osbuild-composer/repositories/rhel-90.json
      "baseurl": "https://cdn.redhat.com/content/dist/rhel9/9.0/x86_64/baseos/os",
      "baseurl": "https://cdn.redhat.com/content/dist/rhel9/9.0/x86_64/appstream/os",


But I'm still getting the same depsolve

[root@r9 ~]# composer-cli blueprints depsolve test  | grep kernel
    kernel-modules-5.14.0-162.6.1.el9_1.x86_64
    kernel-core-5.14.0-162.6.1.el9_1.x86_64
    kernel-5.14.0-162.6.1.el9_1.x86_64



~~~~~~~~~~~~~~~~
Testing on RHEL 8 I see similar incorrect behaviour. Picking the lowest release of 8.4, I am getting 8.6 content. 

[root@r8-imagebuilder ~]# composer-cli  blueprints depsolve test | grep kernel
	    kernel-core-4.18.0-372.32.1.el8_6.x86_64
    kernel-modules-4.18.0-372.32.1.el8_6.x86_64
    kernel-4.18.0-372.32.1.el8_6.x86_64

[root@r8-imagebuilder ~]# cat test
name = "test"
description = ""
version = "0.0.0"
packages = []
modules = []
groups = []
distro = "rhel-84"

John, have you restarted the service (or just the whole machine) before depsolving again? osbuild-composer doesn't check for changes in the repository overrides after the initial start, so you need to restart it. FTR, I would recommend rebooting the whole machine, we have some reports that restarting just the service doesn't always work and we haven't been able to track the root cause just yet.

Also, I have an additional question: Which content does the customer actually want? EUS, or non-EUS?

For non-EUS, that would be /content/dist/rhel9/9.0/ on the CDN, but since 9.0 is already in the EUS-phase, the directory doesn't get any updates since the 9.1 release.
For EUS, the directory is /content/eus/rhel9/9.0/, which is the source of our EUS-phase package updates. The customer has to have a subscription that contains EUS, though.

Testing on r9 (as my r8 image builder box is just not working), I am seeing 9.1 vs 9.0 depsolve correctly. Though am I correct in understanding that you're saying if I change the distro on a blueprint I have to potentially reboot my machine everytime? or only when adding an /etc/osbuild-composer/repository override?

Just when adding an /etc/osbuild-composer/repository override, no need to reboot your machine between depsolves.

Can you elaborate more on your broken r8 box? Is this tracked somewhere?

Finally, can you discuss the EUS vs. non-EUS question with the customer? This is actually a very important item for the team in order to better understand their needs.

> Can you elaborate more on your broken r8 box? Is this tracked somewhere?

No the system had .. personal issues. I've rebuilt it and it no longer has any issues.

> Finally, can you discuss the EUS vs. non-EUS question with the customer? This is actually a very important item for the team in order to better understand their needs.

I can ask them though I am not sure of the intent here. If the customer wants the latest 9.0 content, they will need to use EUS, in which I would have to direct them to make a custom /etc/osbuild-composer/repositories file since we don't have any method of enabling EUS outside of this. Just on that thought, I feel like I need to open some sort of RFE for any osbuild users to be able to switch to EUS when applicable.

(In reply to jcastran from comment #9)
> I can ask them though I am not sure of the intent here. If the customer
> wants the latest 9.0 content, they will need to use EUS, in which I would
> have to direct them to make a custom /etc/osbuild-composer/repositories file
> since we don't have any method of enabling EUS outside of this. Just on that
> thought, I feel like I need to open some sort of RFE for any osbuild users
> to be able to switch to EUS when applicable.

I absolutely agree with the RFE and that's exactly why I want to collect some data from users what they actually want, so we know the scope of the RFE. Thanks!

So I think we can actually close this RFE, since osbuild-composer already has support for building different minor versions. Do you agree?

Note to myself: Also close https://bugzilla.redhat.com/show_bug.cgi?id=2161665 if we decide to close this one.