Set empty values for Unleash server for ros-ocp-backend components

[masayag]

Once RedHatInsights/ros-ocp-backend#657 is merged and ros-ocp-backend image is released and bumped within the chart, the env-vars needs to be nullified to avoid reaching out to Unleash server which is excluded from the on-prem deployment.

UnleashClientAccessToken
UnleashHostname
UnleashScheme
UnleashPort
UnleashFullURL

[ELK4N4]

Can you give more details?
I see they moved those flags into the if statement but in the else part.
So in case CLOWDER_ENABLED=false this code block will run.
It's the same flow like before in our case.

[masayag]

More details: https://redhat-internal.slack.com/archives/C01C1GVT3TP/p1779287132316139

[ELK4N4]

1. This issue should already exists today, before the PR.
   ROS calls featureflags.Init() regardless of Clowder, they're already failing to reach Unleash on every startup.

2. Setting env vars to empty strings won't fix it. Unleash.Initialize will still error, and UnleashPort (an int field) will crash the pod on unmarshal. The right fix is an app-level flag (UNLEASH_ENABLED) that skips featureflags.Init() entirely.

Am I missing something?

[masayag]

I think that updating to the latest ros-ocp-backend should produce the errors to provide you the missing data.

[ELK4N4]

I deployed the chart with both the current ROS version (410b86b) and the latest (6771b81). Neither produces any Unleash-related errors. The processor starts normally and logs "Unleash client initialized successfully":

time="2026-06-17T11:13:06Z" level=info msg="Unleash client initialized successfully" service=ros-processor

This is expected. PR #657 only moved the Unleash defaults from the shared config section into the else (non-Clowder) block. Since on-prem always runs with CLOWDER_ENABLED=false, we hit the else block in both versions — the Unleash client was initialized before and still is after the change.

The Unleash Go SDK's Initialize() is asynchronous — it creates the client and returns immediately without making a network call. Connection failures happen in a background goroutine and are silently discarded by the SDK's default NoopListener. So even though there is no Unleash server in the on-prem deployment, Initialize() always succeeds and no error is ever surfaced.

[masayag]

there is a probability the final version of the PR changed from the version in which the issue seems to affect the code.
what used to be in one of the drafts (was too long ago) - setting env vars was moved from one block to outside of it.
in any case, to harden the configuration of the on-prem, it would be wise to have a dedicated code path for configuring it instead of sharing it with local development (non-clowder path)

[ELK4N4]

So you are talking about adding new UNLEASH_ENABLED flag to ROS repo?

[masayag]

No, to add a specific case for on-prem configuration as proposed in the slack thread.