-
Notifications
You must be signed in to change notification settings - Fork 331
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
Provide option to exclude a registered informer from starting #2976
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: skonto 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 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2976 +/- ##
==========================================
- Coverage 78.70% 78.61% -0.10%
==========================================
Files 188 188
Lines 11051 11069 +18
==========================================
+ Hits 8698 8702 +4
- Misses 2090 2104 +14
Partials 263 263 ☔ View full report in Codecov by Sentry. |
Nice :) |
@dprotaso gentle ping, could you pls review? |
@dprotaso gentle ping, could you pls review? |
@dprotaso gentle ping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you see a non-started informer to be started?
The component holding the informer needs to be restarted, as this stuff happens on Not super ideal, but IMHO still better than installing/updating a separate component :) |
I wonder if in that case using manually creating informers is easier? infX := factory.Get(ctx).ForResource(...)
infY := factory.Get(ctx).ForResource(...)
... := controller.StartInformers(ctx, infX, infY)
// use infX and infY |
I think we (as in the controller in Serving) do not know the informers, as they are added dynamically based on what packages are imported (they self-register in their |
I think you do, you need to avoid importing the injection informers for optional resources and just import the factory package and the concrete informers (if really needed) |
AFAIK, the Serving controller itself holds multiple "subcontrollers". The parent one starts all the informers (via sharedmain) that are on the context (so it does not know which ones upfront). The subcontrollers add them to the context indirectly based on the init functions. So IMHO we would need to change quite a lot to do that. I mean here we just want to ignore a specific one when the CRDs are not installed. Maybe @skonto has something to add? |
Example on the serving PR: import "knative.dev/serving/pkg/net-certmanager/client/certmanager/injection/informers/factory/factory"
// ...
func NewController( ... ) *controller.Impl {
infCertificates := factory.Get(ctx).Certmanager().V1().Certificates().Informer()
... := controller.StartInformers(ctx, infCertificates)
// ...
} |
You need to avoid importing packages like this to opt-out of injection for that informer: "knative.dev/serving/pkg/net-certmanager/client/certmanager/injection/informers/certmanager/v1/certificate/certificate" |
I thought about that I didn't want to re-write too much the main function for the controller we already have that for autoscaler, activator and wanted to provide a feature.
Yes because of the init thingy though I want to be able to start something on demand so I need to have it injected if I dont create it dynamically. |
It is not, it is simply going to be excluded and never started. |
With the solution I'm suggesting, the main function will remain to be the one that is currently on
isn't this possible with the alternative solution? |
What I am saying unless you expand main then you don't report the started informers correctly because you use the factory to create them on demand within the targeted controller. See https://github.com/knative/pkg/blob/main/injection/sharedmain/main.go#L230. That is what I meant create it as a feature, go through main. Btw you need to wait for the cache to be populated after startup which is a different UX.
The idea of dynamic informers to avoid restarts has been around for sometime but it would be nice if main did support that. I don't mind closing this PR and just creating/starting the informer in the corresponding controller but let's wait for @dprotaso and his take on this one. |
It would be good to add flexibility to our codegen that does the injection eg. If can add an option to make this pkg/codegen/cmd/injection-gen/generators/informer.go Lines 109 to 120 in 2c15a6f
Then in our mains we could decide to register the informer like so injection.Default.RegisterInformer(WithInformer) |
I wanted some quick fix to unblock stuff, but maybe doing a more long term solution wrt codegen is more beneficial. I will take a look on the codegen approach. |
closing in favor of #2989 |
Changes
This works because injection via an init func stores instances of cache.SharedIndexInformer, it calls
inf.Informer()
, which are unique at the k8s client go side (one per watched resource type). Thus we can always get back the same instance (inf.Informer()
) and compare.Output in controller logs without any flag set:
In config-network cm we set
external-domain-tls: enabled
, install cert-manager and then delete the previous controller pod:All related informers are started.
/kind enhancement
Release Note
Docs