Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a dynamic caching layer that establishes watches utilizing a ServiceAccount #974

Open
Tracked by #737
everettraven opened this issue Jun 25, 2024 · 2 comments · May be fixed by #1001
Open
Tracked by #737

Implement a dynamic caching layer that establishes watches utilizing a ServiceAccount #974

everettraven opened this issue Jun 25, 2024 · 2 comments · May be fixed by #1001
Assignees

Comments

@everettraven
Copy link
Contributor

everettraven commented Jun 25, 2024

As part of managing installed content and reconciling any changes made to the managed content, we need to configure watches on the resources managed for a given ClusterExtension. After #971, given a ClusterExtension and the content to be managed, we can configure clients for establishing watches using the ServiceAccount specified in the ClusterExtension.

While the exact implementation may vary, the currently proposed approach is as follows:

For each ClusterExtension:

  • Uses a similar approach as the helm-operator-plugins client.RestConfigMapper to generate a rest.Config that uses a token from the ServiceAccount provided in ClusterExtension.Spec.ServiceAccount.Name
    • In order to support authentication token refreshing during a watch, we will need to do some further customization to the rest.Config resource. In order to achieve this, we will implement a custom http.RoundTripper that will set the Authorization HTTP header to a valid token retrieved from the “TokenGetter” object. This is a similar approach that is taken by client-go to utilize a BearerTokenFile. The custom http.RoundTripper we create could be a lighter weight wrapper around the default used by client-go that can be configured via the rest.Config.WrapTransport option that uses a transport.WrapperFunc.
  • Configures a new controller-runtime cache.Cache with the generated rest.Config
    • Note: It may be nice to have a lightweight abstraction on top to simplify the logic within the ClusterExtension reconciler for creating new caches and establishing watches for the managed resources
  • Uses the existing approach for establishing watches with the controller.Controller Watch() method
  • Starts the cache
  • When a ClusterExtension is deleted, it’s cache is stopped and removed

A mermaid graph to visualize the logical flow:

graph TD
    A(ClusterExtension)
    B(Content To Manage)
    C(Managed Content Cache)
    D(RestConfigMapper)
    E(rest.Config)
    F(cache.Cache)
    G(controller.Watch)
    J(ClusterExtension Reconciler)
    L(Watch)

    A -- Provided To --> C
    B -- Provided To --> C
    C -- Fetches Rest Config --> D
    D -- Creates for ServiceAccount --> E
    C -- Creates --> F
    E -- Provided To --> F
    F -- Provided To --> G
    G -- Creates --> L
    L -- Events Trigger --> J
    C -- Establishes Watch With --> G
Loading

Acceptance Criteria:

@joelanford
Copy link
Member

Is it possible to wire up and use a controller-runtime cache-delegating client.Client per ClusterExtension, where we configure it with an http.Client with the custom http.RoundTripper?

@everettraven
Copy link
Contributor Author

@joelanford I've updated the RFC and this issue to now reflect the ideal use of the existing controller-runtime caching layer APIs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Implementing
Development

Successfully merging a pull request may close this issue.

3 participants