tigerquoll commented on code in PR #1060:
URL: https://github.com/apache/yunikorn-k8shim/pull/1060#discussion_r3766751767
##########
pkg/client/apifactory.go:
##########
@@ -89,9 +90,12 @@ type APIFactory struct {
lock *locking.RWMutex
}
-func NewAPIFactory(scheduler api.SchedulerAPI, informerFactory
informers.SharedInformerFactory, configs *conf.SchedulerConf, testMode bool)
(*APIFactory, error) {
+// NewAPIFactory creates the clients shared by the shim. The clientset backing
informerFactory
+// is passed in so that the namespaced factory created here shares it: both
only run informers
+// so they need the same unlimited client and the same attribution.
+func NewAPIFactory(scheduler api.SchedulerAPI, informerClientSet
kubernetes.Interface, informerFactory informers.SharedInformerFactory, configs
*conf.SchedulerConf, testMode bool) (*APIFactory, error) {
kubeClient := NewKubeClient(configs.KubeConfig)
Review Comment:
I think the writes client is the right one here, and it's what master
already does: this PR doesn't touch `LoadConfigMaps`, it just gives the client
it uses a name and a policy. There's no "reads" client to switch to - the
informers clientset exists only to back the informer factories and isn't
exposed in `Clients`, deliberately, so that list/watch traffic stays isolated
and attributable. The bootstrap client wouldn't be right either: it exists to
run before the configuration is loaded, so it builds from the default
kubeconfig path rather than the configured one, and its user agent is meant to
mark startup traffic only.
So the writes client carries the must-complete, direct request/response
traffic. The name is perhaps a little loose: apart from the configmap loads -
two GETs, once per process, at registration - everything on it is either a
mutation (pods, plus PVCs via the volume binder) or a read in service of one,
like the pod GETs inside the update retry loops. I've added a comment on
`Clients` in the latest push spelling out what each client carries.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
