search

kubernetes-sigs / controller-runtime

Repo for the controller-runtime subproject of kubebuilder (sig-apimachinery)
Apache License 2.0
2.43k stars 1.12k forks source link

Plan for Injector interface deprecation #1433

Open DirectXMan12 opened 3 years ago

DirectXMan12 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

/lifecycle frozen

troy0820 commented 3 weeks ago

We removed this in v0.15.0, can we close this issue @vincepri

Remove dependency injection functions (https://github.com/kubernetes-sigs/controller-runtime/pull/2134, https://github.com/kubernetes-sigs/controller-runtime/pull/2120) The package pkg/inject has been removed, this package contained long deprecated injection functions (like InjectScheme, InjectLogger, InjectConfig, InjectClient, InjectCache, etc.). The runtime injection functionality has been deprecated since Controller Runtime 0.10; all of the above fields can be passed from the Manager to structs or interfaces that need them.