Plan for Injector interface deprecation

[DirectXMan12]

So, we filed the injector interface deprecation notice on pkg/inject (#1322). What's the actual rest of the plan for this? We should track this & provide a loose plan for what we're gonna do and what people should expect.

cc @varshaprasad96

[varshaprasad96]

@vincepri @alvaroaleman @estroz
inject functionality was to be deprecated since it would eventually get hard to maintain the codebase wherein we define interfaces/functions for each of the types which are to be propagated to other components registered with manager. Though we have mentioned that manager.Options can be used instead of this in manager, we are still using injectors in the following places:

1. handler (to inject fields into mapper)
2. controller (while setting up watch: to inject cache)
3. manager (this could be replaced by using manager.Options)
4. pkg/source (to inject stopchannel which is needed to start source.Channel)
5. pkg/webhook/server.go (to inject field setter in webhook server)
6. Injecting dependencies in cluster config

Pinging here to start a discussion on suggestions for next steps to remove the functionality internally from the above implementations, so that we can deprecate and remove it later.

[parmus]

@varshaprasad96 Would it be possible that we could get an example of how we are meant to use manager.Options in the future. E.g. it is currently unclear to me how a reconcile function controller added with Manager.Add() is suppose to get a hold of a client. So far the documentation just says "Use manager.Options fields directly. This package will be removed in v0.10." It would be really nice with an example of how to migrate.

[alvaroaleman]

Sorry, I missed the notifications here. So yeah, the next steps would be to get rid of all of it internally, which might also entail some breaking changes. There are also examples where its just about removing dead code, source.Channel is one of them.

Generally speaking I would assume that we will deprecate the injection on the release after which we removed it internally and then give at least two releases time for ppl to update their code.

@parmus at this point you are not expected to do anything. You can get a client from the Manager by calling its GetClient method (this doesn't have anything to do with the managers Options). As soon as there is something consumers need to do, it will be in the release notes.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

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

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[vincepri]

/lifecycle frozen