feat: loki schema config management

[UnicornChance]

Description

Feature to manage the loki schemaConfig date and version transitions with helm only changes.

Walk through of what the helm is doing:

• Secret Retrieval: Fetches the loki secret from the loki namespace.
• Default Date Setup: Sets a default date that is 48 hours in the future.
• Initial Result Setting: Initializes the result variable with the default date.
• Check for Secret and Config Data: Verifies the secret and config.yaml file exist.
• Decode and Parse Config Data: Converts the base64-encoded config.yaml from the secret into a readable YAML format stored in a variable.
• Iterate Through Configs: Loops through each configuration in the schema_config.configs list.
• Conditionally Update Result: If a configuration with store set to "tsdb" and version set to "v13" is found, updates the result to the from date of that configuration and stops the loop.
• Output the Result: Outputs the date found or the default date if no matching configuration is found.

Related Issue

Fixes #782

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Steps to Validate

• uds run dev-setup
• npx pepr deploy
• At this point there is a few different configurations to test with the loki behavior the following are what i focused on in my testing:
  • new install of uds-core logging
    • uds run dev-deploy --set LAYER=logging
    • this will test that a new install will set the tsdb "from" date 2 days into the future
  • upgrade from valid tsdb ( meaning the current loki is configured to use tsdb )
    • modify the values.yaml for loki to deploy with tsdb as a static "from" date like "2023-01-12"
    • deploy uds run dev-deploy --set LAYER=logging
    • revert that change to the values.yaml
    • deploy again uds run dev-deploy --set LAYER=logging
    • This should result in the tsdb "from" being left alone and still equal to what was originally set
  • upgrade from loki that wasnt configured with tsdb
    • modify the values.yaml to exclude (comment out or delete) the tsdb schemaConfig entry
    • deploy uds run dev-deploy --set LAYER=logging
    • revert the changes to the vlaues.yaml
    • deploy uds run dev-deploy --set LAYER=logging
    • this should result in the tsdb schemaConfig being created with a date 2 days into the future

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide followed

[noahpb]

Validated all scenarios locally, lgtm! nice work

[sgettys]

Are there any upgrade scenarios we need to run for this? Also should we do a docs update on the what/why for doing this and how to override?

[mjnagel]

This should probably be documented as an override for a bundle since that is the main way an end user would be interacting with this. I think this is the right syntax but probably good to validate:

  - name: core
    repository: ghcr.io/defenseunicorns/packages/uds/core
    ref: x.x.x
    overrides:
      loki:
        loki:
          values:
            # Setting this value will override the default auto-lookup behavior
            - path: loki.schemaConfig.configs
              value:
                # Self-manage configs here, making sure to include any previous dates you used
                - from: 2022-01-11
                  store: boltdb-shipper
                  object_store: "{{ .Values.loki.storage.type }}"
                  schema: v12
                  index:
                    prefix: loki_index_
                    period: 24h
                # Example: Explicitly set a date for TSDB and the v13 schema, making sure this is in the future
                - from: 2025-03-25
                  store: tsdb
                  object_store: "{{ .Values.loki.storage.type }}"
                  schema: v13
                  index:
                    prefix: loki_index_
                    period: 24h

[mjnagel]

This might also be helpful to have an example override for. Would also maybe link to the upstream docs on changing the schema and specifically call out the nuances around making sure the date is in the future (and specifically future with timezones): https://grafana.com/docs/loki/latest/operations/storage/schema/#changing-the-schema