search

canonical / istio-operators

Charmed Istio
2 stars 17 forks source link

Use secrets configuration instead of wrapping the secret in action #398

Closed DnPlas closed 4 months ago

DnPlas commented 6 months ago

Context

394 and #397 introduced an action to pass TLS certs and keys to istio-pilot to save them as charm secrets and configure the Ingress Gateway with TLS. On https://github.com/canonical/istio-operators/issues/380#issuecomment-2020861148 it is suggested to replace the action with a configuration option and use user secrets instead.

Please note that for this refactor, the desired juju version to use is 3.4, as juju 3.1 does not support user supplied secrets. Please check https://github.com/canonical/bundle-kubeflow/issues/859 for more details on the migration.

What needs to get done

Replace the logic in the charm that observes the action and use a configuration option to pass user secret IDs. This requires us to:

  1. Remove the set-tls and unset-tls actions
  2. Add a configuration option to save user secret IDs
  3. Use the secret ID to retrieve the contents of the secret
  4. Write some unit tests for this

This change has to be done both in main and track/1.17

Definition of Done

The set-tls and unset-tls actions are removed and replaced with a configuration option to pass user secrets.

syncronize-issues-to-jira[bot] commented 6 months ago

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5501.

This message was autogenerated

DnPlas commented 6 months ago

An initial approach at solving this issue has been made in #401. Please note some test cases in that PR are skipped because of https://github.com/canonical/operator/issues/1175.

EDIT: The issue for tracking the missing testing bits is https://github.com/canonical/operator/issues/1166, the team has expanded the scope and will include the fix for testing as well as support for the secrets config type.