The purpose is to simplify Loki configuration for NetObserv, by automating whatever can be deduced from a LokiStack.

Currently, users have to figure out how to configure:

• 3 different URLs
• TLS
• TenantID
• Role + Role binding (which need to be installed apart, and is error prone when used with Kafka bc the FLP service account differs)

Adding a reference to an installed LokiStack object would allow to automate all of that.

The proposal is to introduce a discriminated union, that will guide the user through the correct configuration depending on their Loki scenario, ie. depending on how Loki was installed.

4 options are proposed via this union, which correspond to the install modes we already consider, but would then be made more explicit:

• LokiStack
  • Fields: name, namespace ( = reference to a LokiStack object)
• Monolithic
  • Fields: url, tls, tenantID ( = configuration to a single-endpoint monolithic loki)
• Microservices
  • Fields: ingesterUrl, querierUrl, tls, tenantID ( = configuration to a multiple-endpoints distributed loki)
• Manual
  • Fields: ingesterUrl, querierUrl, statusUrl, tls, statusTls, tenantID, authToken ( = manual configuration, like it is already ; except renaming "url" to "ingesterUrl" )

A positive side-effect is that it will make having default values for fields that suits for each installation mode.

The new lokistack mode will automatically set the various urls, TLS and the tenantID. It seems there is no need to read the LokiStack itself: everything can be inferred from its name+namespace alone. (Which is a good thing a it reduces the coupling surface).

When a lokistack is referenced, the corresponding role YAML should automatically be created/updated. It needs to set the correct FLP service account depending on whether kafka is used.

Note: at the moment, we don't plan for backward compatibility with old versions of the Loki operator. I.e. if URLs / TLS generation changes from a version to another, we would only consider the latest. Users can still fallback to the manual mode if they are affected - or we can revise handling backward compatibility later.