more options for BaseProduct.type

[ktdreyer]

The latest in-development version of my Ceph 3.0 layered product is based on a not-yet-available version of RHEL (7.4).

I was hoping I could specify this in the compose metadata (setting base_product_type = "nightly" in my Pungi config), but it looks like we restrict BaseProduct.type to productmd.common.RELEASE_TYPES:

RELEASE_TYPES = [
    "fast",
    "ga",
    "updates",
    "eus",
    "aus",
    "els",
]

What would be the best way to indicate in the compose metadata that my layered product is based on a not-yet-released base product?

[lubomir]

nightly is a compose type, which is orthogonal to release type.

Why not use ga? Why should the fact that the base product is not released yet change anything?

Alternatively, can you check release_type in a compose of the base product? I think you should use the same value.

[ktdreyer]

re: why not use ga? Good question, I should explain more.

The purpose of this feature would be to standardize how I indicate my product's test environment.

I want to indicate to our QE team and associated test tools that "this compose should be used with a RHEL pre-release". That way, I can point our tools at a compose URL and say "go test this", and the tooling uses productmd to look up what sort of compose it is and what sort of environment it needs. That way I don't need to hardcode decisions like "if release is Ceph 3.0, use RHEL 7.4, otherwise use the latest RHEL GA".

Another option I'm considering is to look up the gather_lookaside_repos setting from Pungi's config-dump JSON, because that will differ between RHEL GA and a RHEL pre-release. It will even give me the exact URLs Pungi used for repoclosure.

I'm just brainstorming at this point. I was just wondering about your thoughts regarding whether it makes sense to put this into productmd.

[lubomir]

Oh I see, I incorrectly assumed base product version uses the usual MAJOR.MINOR schema. However it's only the major version.

So your use case is that both 3.0 and the previous version are based on RHEL-7, but one should use the released version and the other the pre-release version. Correct?

We could add a new release_type such as pre_release, but I see a few issues.

• Even the pre-release composes of RHEL will have release type set to ga, so there will never be an actual compose of a pre-release product marked as such.

• Another issue is that base product type is reflected in release ID. So now you would be composing ceph-3.0@rhel-7-pre_release, and once the base product is actually released, your release ID would change to ceph-3.0@rhel-7. For example from Product Definition Center point-of-view those will be different releases.