[rancher] Cannot easily test SCC Operator in all pre-release use cases

[mallardduck]

Describe the Issue

During the development process of SCC Operator we go through various phases that require different default behaviour. Currently the Operator is not fully able to support every mode we need to test in. We have this behaviour due to varying shifting requirements as it was earlier in development and the recent containerization effort left things behaving a bit odd.

Here are the use-cases I can imagine we need to cover:

	Use Prod SCC	Send Rancher version.Version value	Version Sent
Main Dev Cycle	false	false	"other"
Dev Prod Integration	true	false	"other"
Dev Prod Integration w/Override	true	false	Sends a real previous stable version - via Env override
Rancher Alpha's	false	false	"other"
Rancher Alpha's w/Override	true	false	Point to Prod SCC and send previous real version via Env overrides
Rancher RCs	true	false	Version minus the "-rc.*" (Pre-release part removed)
Rancher Stable	true	true	Unmodified Version

Background

There are some basic requirements to keep in mind while solving this issue, these are:

• The SCC (SUSE Customer Center) does not have a universal "Rancher" Product - every version is a unique Product Label,
• The Product Label is constructed by the SCC library (connect-ng) using a "product triplet"; consisting of Product, Version, Arch (which is: Rancher, Other/{real version}, unknown)
• If a version is not in the SCC it cannot be used for registration and we must use "other" as the version instead
• The SCC API URL selection logic (for default value) is based on CATTLE_DEV_MODE
• The logic to decide to send the raw Rancher version or "other" is based on CATTLE_DEV_MODE

Proposed Fixes

Roughly speaking, these fixes are still the long term goal. However, the SCC Operator is currently built both with lots of bias to 1 Product = 1 Operator; and SCC-Operator is for Rancher by default. Long story short, fixing this before properly supporting multiple products (even just in theory) will complicate the solution too (and require lots of rebases later).

Product Version picking improvement:

Should implement all these:

Revert "other" version logic back to prior version

Previous versions of the logic (before containerization) actually parsed the Rancher version identify if it is valid SemVer. This logic was able to ensure that if we found a Pre-release section of the version then we sent "other" as the value.

Introduce a Dev override for testing various product versions

Along with above change, we will introduce an Env var that can be used to set a specific version.

Stop using CATTLE_DEV_MODE for selecting version all together

Simple as that.

SCC URL picking improvement

Introduce a new SCC_DEV_MODE to scc-operator

Unlike CATTLE_DEV_MODE the SCC_DEV_MODE dev mode will parse the value set - so it will respect false truthy string values as being false (i.e. disable mode). Where as any value set to CATTLE_DEV_MODE are considered as true.

Modify Rancher's SCC Deployer to use SCC_DEV_MODE

Adjust Rancher deployer to set SCC_DEV_MODE env on the SCC deployment based on: a) if it is set by user on r/r (copy this variable like other Envs), or b) Rancher version is not a prod build with SemVer version set then set SCC_DEV_MODE=true.

Adjust URL picking logic to rely on SCC_DEV_MODE

When set true (and the SCC Environment is set to target SCC; not RMT/RGS/etc) we use Staging SCC URL, otherwise we use Prod URL.

[mallardduck]

Potential "Aim I in Dev or Prod" signals to use:

• CATTLE_DEV_MODE - This has extensive uses across rancher codebase; most important context is that when Devs run in an IDE this must be enabled. In the r/r codebase this also controls varying things like: determines if Rancher exec uses jail, controls behaviour of various paths, modifies a few controllers to have their internal devMode set.
• Rancher's version.Version value - Parsing the version.Version that Rancher is compiled with is probably the most important signal since Production images are reliably "Prod SemVer" values. Yes - devs
• {RANCHER|CATTLE}_DEBUG env - This is used for setting the logger to Debug mode.

Given these potential signals - the main signal we should rely on is Rancher's version.Version value. This is a signal we know that has reliable value states in Rancher's official build lifecycle. However, we should still have a secondary method to override the value for internal use cases where we need to control the behaviour.

Effectively this all means we create a new bool for this signal and use that to decide various SCC operator defaults too. Then each of those defaults could have ENV overrides like the version one.

SCC Operator Decisions

• Which SCC API URL to use,
• Which version value to report to SCC (both needed for metrics value and Rancher Product code)
• (Less critical) What time interval to use for the Online mode "keepalive" checkin

---

Possible (Common) Configurations

Rancher build and Version Facts

	Rancher Version	CATTLE_DEV_MODE	NOTES
Dev's IDE	"dev"	true - Required in IDE
Dev Built Image	"v2.12-207d1eaa2-head"	false	Using dev-scripts/quick w/o Args. The version listed is an example of the version style.
Dev Built w/Tag	Can be any value set	false	Using dev-scripts/quick w/ TAG set to override. (Can be used, with other args, to make a "fake prime stable" pushed to a Dev's fork)
Rancher Head Images	"v2.12-207d1eaa2-head"	false	Head images and dev-scripts/quick share the same logic for Version tag craetion
Release Team Pre-Release (alpha/rc)	"v2.12.1-alpha4"	false
Release	"v2.12.0"	false

Possible SCC Envs
Production (SCC)
Staging (SCC)
PayAsYouGo
RGS
default ("unknown")

Expectations

Rancher Version	CATTLE_DEV_MODE	SCC_RANCHER_VERSION_OVERRIDE	Expected SCC Env	Expected Version	Expected SCC URL
"dev"	true - Required in IDE
"v2.12-207d1eaa2-head"	false
Can be any value set	false
"v2.12-207d1eaa2-head"	false
"v2.12.1-alpha4"	false
"v2.12.0"	false

[mallardduck]

It's very clear now that after the issue we ran into today the solution we land on needs to not care as much about Rancher biases.

We need to create a more "product universal" solution for this concept - and then ensure that can be used as a "configuration framework" that enables the use-cases specific to various phases of Rancher development. (And will be compatible with future expansion to other non-Rancher Prime based SUSE Products too; SUSE virtualization which is Rancher based and SUSE Observability which is not)

In other words, I will need to shift my focus to a two layered approach where SCC Operator can act more universally - and the Rancher Core code that handles "SCC Deployer" will translate Rancher biased processes/signals into the universal configs SCC Operator will utilize.

[mallardduck]

Splitting up the fix for this across easier to review PRs:

• Just refactors: General refactors fixes #49
• New Config System: Implement new Config system #50
• Start decoupling Rancher specific logic: Improve product support - to eventually support other ECM products #51