✨ Support serviceaccount pull secrets #2005
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
tmshort
force-pushed
the
use-sa-pull-secret
branch
from
d09d1b8 to
26246b6
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2005 +/- ##
==========================================
+ Coverage 69.17% 69.54% +0.36%
==========================================
Files 79 79
Lines 7037 7144 +107
==========================================
+ Hits 4868 4968 +100
- Misses 1887 1889 +2
- Partials 282 287 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
/hold |
openshift-ci
bot
added
the
do-not-merge/hold
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: tmshort The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
tmshort
force-pushed
the
use-sa-pull-secret
branch
from
26246b6 to
11579bc
Compare
Serviceaccounts reference pull secrets! * Determine our serviceaccount (via the new internal/shared/util/sa package). * Use a common pull_secret_controller * Update the pull_secret_controller to know about the service account * Update the pull_secret_controller to watch the namespace-local secrets * Update caching to include sa, and use filters for additional secrets * Add RBAC to access these secrets and sa * Update writing the auth.json file to handle dockercfg and dockerconfigjson * Update writing the auth.json file to include multiple secrets Signed-off-by: Todd Short <[email protected]>
tmshort
force-pushed
the
use-sa-pull-secret
branch
from
11579bc to
1c0e4dd
Compare
|
/unhold |
openshift-ci
bot
removed
the
do-not-merge/hold
| AuthFilePath string | ||
| } | ||
|
|
||
| func (r *PullSecretReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { |
There was a problem hiding this comment.
Is req used anywhere other than logging? If not, I think I'd suggest dropping it (e.g. rename to _). And changing the logging to just generically say something like "reconciling pull secrets".
The name/namespace of the request without the type info might be a little confusing to show up in the log. But maybe we could log the events that pass our predicate in our predicate where we do have type information. That way there's still detail about what is causing our reconciler to be triggered?
There was a problem hiding this comment.
Interestingly... the logger has a lot of additional information added to it, so you can tell what type of resource triggered the event, I wrapped the log below to make it easier to read:
I0606 18:43:42.641045 1 pull_secret_controller.go:113] "found secret"
logger="pull-secret-reconciler"
controller="service-account-controller"
controllerGroup=""
controllerKind="ServiceAccount"
ServiceAccount="olmv1-system/operator-controller-controller-manager"
reconcileID="26404229-a2d3-495d-86ee-0da390a1e8f4"
name="pull-dockercfg"
namespace="olmv1-system"
There was a problem hiding this comment.
And when a pull secret is modified:
I0606 18:58:10.831129 1 pull_secret_controller.go:113] "found secret"
logger="pull-secret-reconciler"
controller="pull-secret-controller"
controllerGroup=""
controllerKind="Secret"
Secret="olmv1-system/pull-dockercfg"
reconcileID="a783ca58-0213-4fe3-a19d-3ed7ca21f5ae"
name="pull-dockercfg"
namespace="olmv1-system"
| _, err := ctrl.NewControllerManagedBy(mgr). | ||
| For(&corev1.Secret{}). | ||
| Named("pull-secret-controller"). | ||
| WithEventFilter(newSecretPredicate(r)). | ||
| Build(r) | ||
| if err != nil { | ||
| return err | ||
| } | ||
|
|
||
| _, err = ctrl.NewControllerManagedBy(mgr). | ||
| For(&corev1.ServiceAccount{}). | ||
| Named("service-account-controller"). | ||
| WithEventFilter(newNamespacedPredicate(r.ServiceAccountKey)). | ||
| Build(r) |
There was a problem hiding this comment.
I don't think I'd setup two separate controllers. IIRC, there's a way to have a single controller with multiple watches. You may need to drop down to the lower-level controller package though (can't remember if For is required).
There was a problem hiding this comment.
TBH, having two controllers actually seems the cleanest, in that we get different invocations that recognize ServiceAccount vs. Secret, and it's clear what triggered the reconcile (i.e. the logger clearly indicates what resource is the trigger). With a single controller, we have to somehow map the ServiceAccount to a set of Secrets (which we may not yet know about yet), which feels kinda kludgy. Otherwise, the Secret controller is getting a ServiceAccount for the request, rather than a Secret.
Signed-off-by: Todd Short <[email protected]>
|
lint doesn't like my logging trick... |
Signed-off-by: Todd Short <[email protected]>
Signed-off-by: Todd Short <[email protected]>
Serviceaccounts reference pull secrets!
Description
Reviewer Checklist