Repository navigation
python kubeconfig loading doesn't match kubectl config loading... #445
Description
Activity
kubectlseems to choose the last one if there are multiple clusters with the same name:The config loader https://github.com/kubernetes/kubernetes/blob/b114a117f8688310b9162961d8e9b15192eacd50/pkg/kubectl/cmd/util/factory_client_access.go#L175-L176
ends up being https://github.com/kubernetes/kubernetes/blob/b114a117f8688310b9162961d8e9b15192eacd50/staging/src/k8s.io/client-go/tools/clientcmd/loader.go#L386-L399, which uses https://github.com/kubernetes/kubernetes/blob/b114a117f8688310b9162961d8e9b15192eacd50/staging/src/k8s.io/client-go/tools/clientcmd/api/latest/latest.go#L59-L65I agree it should detect duplicate entries. Just curious would it solve the problem if the python client chose the last one in the file?
- We need a spec for this or we risk getting on a treadmill...…--brendan________________________________ From: Haowei Cai (Roy) <notifications@github.com> Sent: Wednesday, February 21, 2018 4:25:58 PM To: kubernetes-client/python Cc: Brendan Burns; Author Subject: Re: [kubernetes-client/python] python kubeconfig loading doesn't match kubectl config loading... (#445) kubectl seems to choose the last one if there are multiple clusters with the same name: The config loader https://github.com/kubernetes/kubernetes/blob/b114a117f8688310b9162961d8e9b15192eacd50/pkg/kubectl/cmd/util/factory_client_access.go#L175-L176<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fkubernetes%2Fblob%2Fb114a117f8688310b9162961d8e9b15192eacd50%2Fpkg%2Fkubectl%2Fcmd%2Futil%2Ffactory_client_access.go%23L175-L176&data=04%7C01%7Cbburns%40microsoft.com%7C091188a4cdc248f4cedd08d5798ad98f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636548559623955937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=gQ8LElO00M%2BR5KdavyP2mYcbwOi0MMy4kDFvVArav5A%3D&reserved=0> ends up being https://github.com/kubernetes/kubernetes/blob/b114a117f8688310b9162961d8e9b15192eacd50/staging/src/k8s.io/client-go/tools/clientcmd/loader.go#L386-L399<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fkubernetes%2Fblob%2Fb114a117f8688310b9162961d8e9b15192eacd50%2Fstaging%2Fsrc%2Fk8s.io%2Fclient-go%2Ftools%2Fclientcmd%2Floader.go%23L386-L399&data=04%7C01%7Cbburns%40microsoft.com%7C091188a4cdc248f4cedd08d5798ad98f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636548559623955937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=8IFlpqkIvIG5Z0eg3hQ0lQJOnCSdAgeKuFO4%2F88Noyw%3D&reserved=0>, which uses https://github.com/kubernetes/kubernetes/blob/b114a117f8688310b9162961d8e9b15192eacd50/staging/src/k8s.io/client-go/tools/clientcmd/api/latest/latest.go#L59-L65<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fkubernetes%2Fblob%2Fb114a117f8688310b9162961d8e9b15192eacd50%2Fstaging%2Fsrc%2Fk8s.io%2Fclient-go%2Ftools%2Fclientcmd%2Fapi%2Flatest%2Flatest.go%23L59-L65&data=04%7C01%7Cbburns%40microsoft.com%7C091188a4cdc248f4cedd08d5798ad98f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636548559623955937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=F4xrinp%2FsWHODL64PY99CJTNJgjeysXptURuBa2MawU%3D&reserved=0> I agree it should detect duplicate entries. Just curious would it solve the problem if the python client chose the last one in the file? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes-client%2Fpython%2Fissues%2F445%23issuecomment-367525086&data=04%7C01%7Cbburns%40microsoft.com%7C091188a4cdc248f4cedd08d5798ad98f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636548559623955937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=sKLw90IlUog9wUvfl0pji5NR%2Fe5Q1b9Kv4WfszDwRJw%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFfDghWZgfG4SPOTd6hWTjcLfRvblCQVks5tXLQWgaJpZM4RvK04&data=04%7C01%7Cbburns%40microsoft.com%7C091188a4cdc248f4cedd08d5798ad98f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636548559623955937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=BphayTNl7hrjdN61dhD333JKLgZntHHBB%2F6Hhtmuk0k%3D&reserved=0>.
@brendandburns Totally agree. Just curious if
kubectlin your test was picking the last one or behaving differently. I will open a PR to add the duplication detection.- added a commit that references this issue
on May 19, 2018 - added a commit that references this issue
on May 19, 2018 - added a commit that references this issue
on Jun 8, 2018 - added a commit that references this issue
on Jun 8, 2018
I had a .kube/config file with duplicate clusters with the same name (but different information) in the config file, the three different entries each pointed to different clusters, two were dead, but one was alive (I had be repeatedly creating and deleting clusters)
kubectlcommand line happened to chose the working one and worked correctly.python client library chose the first one in the file (which wasn't working) and failed.
This lead to a very confused experience until I figured out what was going on.
It will be difficult to emulate the
kubectlparsing exactly, but we should detect duplicate entries and throw an exception. (and I would argue thatkubectlprobably should too)This actually probably applies to all client libraries in different languages.
@mbohlool