default to quay based observability resources

[pb82]

With the coming version of KFM, the observability configuration changes and the observability resources are now obtained from quay instead of Github. OBSERVABILITY_CONFIG_ACCESS_TOKEN is no longer used. Github based resources are still supported, but the access token has to be provided as part of a new config file.

Instead, I would suggest to just update the KAS Installer to the new quay location.

NOTE: this can only be merged, once bf2fc6cc711aee1a0c2a/kas-fleet-manager#1647 has landed. The KFM Git ref also needs to be updated one available.

[miguelsorianod]

With the coming version of KFM, the observability configuration changes and the observability resources are now obtained from quay instead of Github. OBSERVABILITY_CONFIG_ACCESS_TOKEN is no longer used. Github based resources are still supported, but the access token has to be provided as part of a new config file.

Instead, I would suggest to just update the KAS Installer to the new quay location.

NOTE: this can only be merged, once bf2fc6cc711aee1a0c2a/kas-fleet-manager#1647 has landed. The KFM Git ref also needs to be updated one available.

Would the credentials to be able to get the quay image need to be set somehow in kas installer?

[pb82]

@miguelsorianod No, the KFM creates the image pull secret in the Observability namespace to pull that image.

[miguelsorianod]

@miguelsorianod No, the KFM creates the image pull secret in the Observability namespace to pull that image.

How/Where does the KFM get the content for the image pull secret?

[pb82]

it's the same dockerconfig.json that also gets added to the FSO namespace, KFM gets it from the service secret in Vault. We have added permissions to the resources repo to the robot account used in there.

[miguelsorianod]

it's the same dockerconfig.json that also gets added to the FSO namespace, KFM gets it from the service secret in Vault. We have added permissions to the resources repo to the robot account used in there.

And KAS Installer gets it from the service secret in Vault?
What you are talking are specifics of KFM Stage / Production environments, which might not be necessarily true for dev environments and for kas installer.

[MikeEdgar]

And KAS Installer gets it from the service secret in Vault?

The pull secret is created by the installer in <KFM Namespace>/kas-fleet-manager-image-pull-secret based on a user-provided username/password.

[miguelsorianod]

And KAS Installer gets it from the service secret in Vault?

The pull secret is created by the installer in <KFM Namespace>/kas-fleet-manager-image-pull-secret based on a user-provided username/password.

Then my original question still applies, would the credentials, which we now know are set by kas installer, be able to get the quay image from the quay repository that contains the observability config?
Do we need to update the documentation of kas installer to make clear that it is a requirement that those credentials must have access to a specific quay repository?

[MikeEdgar]

A few additional notes for when bf2fc6cc711aee1a0c2a/kas-fleet-manager#1647 is merged:

• update the KFM default commit

  kas-installer/kas-installer-defaults.env

  Line 140 in c7e1446

  KAS_FLEET_MANAGER_GIT_REF="${KAS_FLEET_MANAGER_GIT_REF:-"cb483d50818dff77c108908cf80d6454a5a0b1e3"}"

• remove occurrences of OBSERVABILITY_CONFIG_ACCESS_TOKEN (several throughout the repo)

[miguelsorianod]

Do we know what GITHUB_TOKEN is used for? Are we sure it is only used for the part around observability config retrieval?

[pb82]

If I understand this part of the installer code correctly, it was only printing the configuration summary. There are no other references to GITHUB_TOKEN inside the KAS Installer.

[miguelsorianod]

I am not sure of that. It is true that it prints to stdout but in kas-installer the output of the scripts is reused for other elements sometimes.
See https://github.com/bf2fc6cc711aee1a0c2a/kas-installer/blob/main/README.md#running-e2e-test-suite-experimental where it seems the output of that script is used as some kind of configuration

[miguelsorianod]

The changes look good to me. However, we will need to continue the remaining cleanup of kas-installer and the pipelines with @MikeEdgar , as we still see some remaining elements to be cleant.
Let's merge and tag already to fix the e2e pipelines failing after the KFM PR that had been merged.

[MikeEdgar]

LGTM :-)