ENT-5581: Update messaging around the "container mode"

[m-horky]

• Card ID: ENT-5581

[github-actions]

Coverage (computed on Fedora latest) •

File	Stmts	Miss	Cover	Missing
subscription_manager/cli_command
cli.py	209	31	85%	65, 69, 124, 128–129, 144, 201, 205, 207, 250, 289, 300–302, 316–318, 342, 362, 388, 397–398, 402–403, 419, 421–422, 424–425, 430, 438
TOTAL	18158	4563	74%

Tests	Skipped	Failures	Errors	Time
2633	9 💤	0 ❌	0 🔥	1m 3s ⏱️

[jirihnidek]

I think that this changes is not necessary. It will only confuse users.

[ptoscano]

The thing is that, after #3270 and #3292, the detection logic for the "container mode" does not depend on running in a container. In fact, the only way the "mode" will be triggered is the presence of secrets (certificates, config) in certain locations, and nothing else. Hence, I'd argue the opposite: I'd find misleading the message "disabled when running in a container" when subscription-manager would run in a container with no secrets provided; strictly speaking, you don't even need to be in a container to trigger that mode, you can theoretically trigger it even on a VM or baremetal system by placing the entitlement certificates in the places for it.

[jirihnidek]

You are correct that you can theoretically mimic this situation on any system, but it is unlikely that users and customers will do that. Why would they do that?

I would not change this message, because there could be some theoretical edge case. I think that changing this message would be only confusing for existing users.

[ptoscano]

The point of changing the message is avoiding the confusion actually:

• if you start a container and no secrets are provided, subscription-manager will work just fine (as on a baremetal system, or in a VM)
• if you start a container with secrets provided, subscription-manager still disables itself with "disabled when running in a container"

I find this inconsistent, because it is not clear why the first container does not cause subscription-manager to disable itself, even though it is actually running in a container! Since the factor here is only the presence of secrets, then simply tell that to the user, so they know directly why their subscription-manager does not allow them to register/etc.

[jirihnidek]

The point of changing the message is avoiding the confusion actually:

* if you start a container and no secrets are provided, `subscription-manager` will work just fine (as on a baremetal system, or in a VM)

* if you start a container with secrets provided, `subscription-manager` still disables itself with "disabled when running in a container"

It is fair, but IMHO proposed message could be still confusing... What about extending message like this:

Subscription Manager is operating in container mode (secrets in /etc/pki/entitlement-host detected).

We would be messaging that user tries to use subscription-manager inside UBI container and how was container detected.

I find this inconsistent, because it is not clear why the first container does not cause subscription-manager to disable itself, even though it is actually running in a container! Since the factor here is only the presence of secrets, then simply tell that to the user, so they know directly why their subscription-manager does not allow them to register/etc.

[ptoscano]

The point of changing the message is avoiding the confusion actually:

* if you start a container and no secrets are provided, `subscription-manager` will work just fine (as on a baremetal system, or in a VM)

* if you start a container with secrets provided, `subscription-manager` still disables itself with "disabled when running in a container"

It is fair, but IMHO proposed message could be still confusing... What about extending message like this:

Subscription Manager is operating in container mode (secrets in /etc/pki/entitlement-host detected).

I'd still remove the "container mode", that is the whole point of the changes here. There is not much left of "container" here.

We would be messaging that user tries to use subscription-manager inside UBI container and how was container detected.

As I said, being in a container does not have any influence in how subscription-manager behaves now.