Skip to content

Comments

[WIP] Add secret monitor for Routes#1518

Closed
thejasn wants to merge 10 commits intoopenshift:masterfrom
thejasn:feature/secret-manager
Closed

[WIP] Add secret monitor for Routes#1518
thejasn wants to merge 10 commits intoopenshift:masterfrom
thejasn:feature/secret-manager

Conversation

@thejasn
Copy link
Contributor

@thejasn thejasn commented May 2, 2023

Related: CFE-866
Implements: openshift/enhancements#1307

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 2, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented May 2, 2023

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 4, 2023
@p0lyn0mial
Copy link
Contributor

Hi @thejasn, I would like to get some context before I start reviewing this PR (or reading the KEP).
Could you please explain to me why we need this functionality in the library-go ?

@thejasn thejasn force-pushed the feature/secret-manager branch from 1b5e110 to 75490f9 Compare June 6, 2023 05:59
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 6, 2023
@thejasn thejasn changed the title [WIP] Add secret manager for Routes [WIP] Add secret monitor for Routes Jun 6, 2023
@thejasn thejasn force-pushed the feature/secret-manager branch from 75490f9 to 24c65a5 Compare July 11, 2023 08:42
@thejasn thejasn force-pushed the feature/secret-manager branch from 24c65a5 to 88b71e4 Compare July 11, 2023 08:47
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jul 11, 2023

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: thejasn
Once this PR has been reviewed and has the lgtm label, please assign knobunc for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Fixes one-to-many mapping of secret to multiple routes
@thejasn
Copy link
Contributor Author

thejasn commented Jul 11, 2023

/cc @deads2k

@openshift-ci openshift-ci bot requested a review from deads2k July 11, 2023 10:41
}

type Object struct {
RefCount int
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems more suitable as a property tracked by the caller.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I would agree, will rework this bit.

type objectKey struct {
namespace string
name string
uid types.UID
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

top-to-bottom, I'm surprised to see UID.


// Monitor manages Kubernetes secrets. This includes retrieving
// secrets or registering/unregistering them via Routes.
type Monitor interface {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need something like

type SecretEventHandlerRegistration interface{
  ResourceEventHandlerRegistration

  UID() string
}

type SecretMonitor interface{
  AddEventHandler(namespace, name string, handler ResourceEventHandler) (SecretEventHandlerRegistration, error)
  
  RemoveEventHandler(SecretEventHandlerRegistration) error
}

This will allow an eventHandler for every route (overlapping secrets). It's not perfectly efficient, but it is easy. And handler passed in could wire back to a route to be queued in a different controller. Need a link to your calling code to see how to wire that back in.

We might also need a way to get a list of all known eventHandlers to diff against the current state (re-list after an outage), but if the caller correctly handles deletes we may not need it. It is a potential spot for a leak.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the 1.27 SharedInformer interface for where I got inspiration and how can you wire it up through a sharedinformer versus a regular informer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I understand your suggestion as, we need an abstraction between the secret watching logic and And the caller (the component that interfaces with Routes) in form of (do correct me if I understood it incorrectly)

type SecretMonitor interface{
  AddEventHandler(namespace, name string, handler ResourceEventHandler) (SecretEventHandlerRegistration, error)
  
  RemoveEventHandler(SecretEventHandlerRegistration) error
}

See the 1.27 SharedInformer interface for where I got inspiration and how can you wire it up through a sharedinformer versus a regular informer.

Are you also suggesting I replace the use of the regular informer in the implementation with a sharedinformer?

Add SecretEventHandlerRegistration and SecretMonitor
interface as an abstraction for secret watchers and
consume the SecretMonitor via a Manager that interfaces
with routes
@deads2k
Copy link
Contributor

deads2k commented Jul 13, 2023

opened #1554 to adjust the secretmonitor. see if it makes sense.

thejasn added 2 commits July 14, 2023 12:18
Replace informer with sharedinformer
@thejasn thejasn mentioned this pull request Aug 2, 2023
@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 1, 2023
@openshift-bot
Copy link

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci openshift-ci bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Dec 1, 2023
@openshift-bot
Copy link

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-ci openshift-ci bot closed this Jan 1, 2024
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 1, 2024

@openshift-bot: Closed this PR.

Details

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants