jiebi/CodeConvo huggingface dataset:
Change:
var hns HostNetworkService hns = hnsV1{} supportedFeatures := hcn.GetSupportedFeatures() <del> if supportedFeatures.Api.V2 { </del> <ins> if supportedFeatures.RemoteSubnet { </ins> hns = hnsV2{} }

Discussion:
I have been deploying master-branch kubernetes on Windows using flannel/host-gateway networking, with one master, one linux worker, and three windows worker. Recently, kube-proxy stopped running correctly. It exits with an error about not finding the HNS Network. I have confirmed that the HNS network exists on the host with the correct name (cbr0), and have identified the last commit where kube-proxy works. What happened: Starting with the commit merging , kube-proxy outputs the following error message: This is confusing because does show : (nat network removed from above output) What you expected to happen: kube-proxy to work in host-gateway mode. How to reproduce it (as minimally and precisely as possible): Build kubernetes at or after . Start flanneld, kubelet, and kube-proxy on a windows 2019 vm. See kube-proxy fail despite flanneld having created the network. Anything else we need to know?: Environment: Kubernetes version (use ): kube-proxy breaks on commit and later; works on Cloud provider or hardware configuration: vsphere OS (e.g: ): windows server 2019, with up-to-date patches Kernel (e.g. ): windows nodes are , linux master/worker are Install tools: deployed using /sig windows cc
I'm aware of this issue. The fix will be out within an hour.
Change:
// Make the environment variables for a pod in the given namespace. func (kl *Kubelet) makeEnvironmentVariables(pod *v1.Pod, container *v1.Container, podIP string) ([]kubecontainer.EnvVar, error) { var result []kubecontainer.EnvVar <ins> enableServiceLinks := v1.DefaultEnableServiceLinks if pod.Spec.EnableServiceLinks != nil { enableServiceLinks = *pod.Spec.EnableServiceLinks } </ins> // Note:  These are added to the docker Config, but are not included in the checksum computed // by kubecontainer.HashContainer(...).  That way, we can still determine whether an // v1.Container is already running by its hash. (We don't want to restart a container just

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: Kubelet panics after registering node What you expected to happen: Kubelet should not panic How to reproduce it (as minimally and precisely as possible): Use kubelet on an ARM64 machine (i'm on Scaleway provider) Anything else we need to know?: I upgraded from 1.12.3 to 1.13.0 here is the statup log (only the end): Environment: Kubernetes version (use ): 1.13.0 Cloud provider or hardware configuration: Scaleway OS (e.g. from /etc/os-release): Debian GNU/Linux 9 (stretch) Kernel (e.g. ): 4.15.11-mainline-rev1 Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig node
a few questions: can you provide full output of , including the server version? did you upgrade kube-apiserver to 1.13.0? are you running static pod manifests on the kubelet?
hello i had rollbacked this node cannot currently no i didn't. I just upgraded on one server kube-proxy and kubelet. Kube-proxy works fine. i don't have static pods, just daemonsets on this node (metrology)
kubelet must not be newer than kube-apiserver be sure to upgrade kube-apiserver to 1.13 before upgrading kubelet
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
i understand but why not just have a proper error instead of a ugly stack trace then ? it's more proper than an unhandled error. Here it's a memory error, a memory error is a grave error.
/reopen cc for disposition
Reopened this issue. <detailsIn response to : /reopen cc for disposition Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
code in question is here: note that this is an unsupported configuration
Refer the discussion here:
Solved using 1.13.0 api server. But i really think we need to handle this more properly than a stack
Should kubelet mark the node NotReady if it sees an older apiserver?
it sounds reasonable, and if we can have a description on the node saying: not compatible can be better
Change:
taintArgs := []string{} metTaintArg := false for _, s := range args { <del> isTaint := strings.Contains(s, "=") || strings.HasSuffix(s, "-") </del> <ins> isTaint := strings.Contains(s, "=") || strings.Contains(s, ":") || strings.HasSuffix(s, "-") </ins> switch { case !metTaintArg && isTaint: metTaintArg = true

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: says: That doesn't work: It doesn't matter whether there is a node "foo" or not. It doesn't seem to contact the API at all. What you expected to happen: Examples form the help texts should work. Anything else we need to know?: Looking at , it seems to want either a or in the argument. Indeed, does work and does the right thing, i.e. set a taint with key and no value. Environment:
i believe there were updates about this at some point. a PR is welcome /remove-kind bug /kind documentation /sig cli side note: Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-12-11T12:34:17Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"} always make sure the client MINOR version is equal or +1, or -1 of the server MINOR version. in this case it's +2, which is unsupported.
/assign bharaththiruveedula
Do you mind if I submmit a PR on this because I met this issue before?
I assigned the issue today itself and already started working on it. I will send the PR by end of today. But thanks for showing the interest.
Are we updating the documentation or the code now? Right now fails but works (because of the "-"), which isn't very consistent at all, so I'd suggest we actually fix kubectl itself to do what the help page says.
Change:
return err } <ins> if len(e.Subsets) == 0 { // no action is needed to remove the endpoint return nil } </ins> // Remove our IP from the list of addresses new := []corev1.EndpointAddress{} for _, addr := range e.Subsets[0].Addresses {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In kubernetes 1.15, Panic happends in kube-apiserver. Subsets[0] is nil when endpoints has no subsets The Panic happens in here: And everything returns to normal when we delete the endpoints in etcd What you expected to happen: Maybe kube-apiserver should print error,not panic How to reproduce it (as minimally and precisely as possible): The host's iowait of ETCD is high Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:NA OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig release
/remove-sig release /sig api-machinery
/assign
Change:
schedulerapi.DefaultPercentageOfNodesToScore, false) cache.UpdateSnapshot(s.(*genericScheduler).nodeInfoSnapshot) return s.(*genericScheduler) } func TestFindFitAllError(t *testing.T) {

Discussion:
How to reproduce it (as minimally and precisely as possible): pre-requisites: a multi-az cluster, a deployment with 1 pod in each az. a with and . the node(s) in 1 az. the deployment's pod(s) from the cordoned az. What happened: A new pod was created and scheduled in a form that What you expected to happen: I expected that a new pod will be created and be "stuck" in status as it shouldn't have nowhere be scheduled. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ): 4.19.84-coreos Others: I created a with how I reproduce the bug
/sig scheduling
cc/
Thanks for raising this issue. I feel like it's a general timing issue - when you delete a Pod, that Pod may still exist for a very short time (in graceful deletion period), and at the same time, the controller backfills a Pod for it. So when scheduling tries to schedule the backfill Pod, it may read the cluster as: [1, 1, 1(deleting)]. To confirm this, can you try deleting the Pod using , and see if the problem goes away?
Yes sure I will try that. It sounds reasonable, thats why in the first demonstration I deleted all the pods and waited for all of them to completely disappear. Nevertheless, this is still something that I believe needs to be fixed. The pod's evaluation should take in consideration pods that are in status and don't count them as pods.
I do believe we exclude the Pods. (if not, it should be a serious regression). What concerns me is that at that moment, scheduler may treats that (deleting) Pod as running in its cache. I will try to debug into this.
Yep, this time the new pod was in status until I uncordoned the relevant nodes.
Change:
return gce, nil } <ins> // determineSubnetURL queries for all subnetworks in a region for a given network and returns // the URL of the subnetwork which exists in the auto-subnet range. func determineSubnetURL(service *compute.Service, networkProjectID, networkName, region string) (string, error) { subnets, err := listSubnetworksOfNetwork(service, networkProjectID, networkName, region) if err != nil { return "", err } autoSubnets, err := subnetsInCIDR(subnets, autoSubnetIPRange) if err != nil { return "", err } if len(autoSubnets) == 0 { return "", fmt.Errorf("no subnet exists in auto CIDR") } if len(autoSubnets) > 1 { return "", fmt.Errorf("multiple subnetworks in the same region exist in auto CIDR") } return autoSubnets[0].SelfLink, nil } </ins> func tryConvertToProjectNames(configProject, configNetworkProject string, service *compute.Service) (projID, netProjID string) { projID = configProject if isProjectNumber(projID) {

Discussion:
/kind bug What happened: Continuation of . The fix to that bug only takes the first subnetwork in the correct region. However, if the user manual subnets in the region that the cluster exists, it's possible the cloudprovider could choose the wrong subnet. What you expected to happen: If no subnet is specified for a non-legacy network, always take the subnet which was automatically created. /assign /sig network /area platform/gce
Change:
}}, }, }, <ins> { testName:      "endpoint with no subset", serviceName:   "foo", ip:            "5.6.7.8", endpointPorts: []corev1.EndpointPort{{Name: "foo", Port: 8080, Protocol: "TCP"}}, endpointKeys:  []string{"1.2.3.4", "4.3.2.2", "4.3.2.3", "4.3.2.4"}, endpoints: &corev1.EndpointsList{ Items: []corev1.Endpoints{{ ObjectMeta: om("foo"), Subsets:    nil, }}, }, }, </ins> } for _, test := range stopTests { t.Run(test.testName, func(t *testing.T) {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In kubernetes 1.15, Panic happends in kube-apiserver. Subsets[0] is nil when endpoints has no subsets The Panic happens in here: And everything returns to normal when we delete the endpoints in etcd What you expected to happen: Maybe kube-apiserver should print error,not panic How to reproduce it (as minimally and precisely as possible): The host's iowait of ETCD is high Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:NA OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig release
/remove-sig release /sig api-machinery
/assign
Change:
dc.sync(ctx, pdbName) ps.VerifyDisruptionAllowed(t, pdbName, 0) <ins> verifyUnsupportedControllerEventEmitted(t, dc) </ins> } // Verify that disruption controller is not erroring when unmanaged pods are found

Discussion:
When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
expectedContainer: "bar", name:              "container in flag", }, <ins> { p:                 &AttachOptions{ContainerName: "initfoo"}, args:              []string{"foo"}, expectedPod:       "foo", expectedContainer: "initfoo", name:              "init container in flag", }, </ins> } for _, test := range tests { f, tf, codec := NewAPIFactory() tf.Client = &fake.RESTClient{

Discussion:
Related issue
is there a simple example that you used to recreate the problem?
I used exactly the example below: So Pod sflask-w-init gets into pending state "Init:0/1" forever. Then you can try to run and you can see that is not working while invoking corresponding command with docker works - it displays current date every second.
thanks for the detailed test, please see the PR :)
Duh! already has a PR
Change:
} func (config *NetworkingTestConfig) createNodePortService(selector map[string]string) { <del> config.NodePortService = config.createService(config.createNodePortServiceSpec(nodePortServiceName, selector, false)) </del> <ins> config.NodePortService = config.CreateService(config.createNodePortServiceSpec(nodePortServiceName, selector, false)) </ins> } func (config *NetworkingTestConfig) createSessionAffinityService(selector map[string]string) { <del> config.SessionAffinityService = config.createService(config.createNodePortServiceSpec(sessionAffinityServiceName, selector, true)) </del> <ins> config.SessionAffinityService = config.CreateService(config.createNodePortServiceSpec(sessionAffinityServiceName, selector, true)) </ins> } // DeleteNodePortService deletes NodePort service.

Discussion:
What happened: indicates that we're missing an e2e test for. This specific issue is just a tracker to create a new E2E test that demonstrated .
/sig network
/assign
btw, should this be a part of conformance?
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
I can start working on this.
Sure/ are you working full time on it ? If so I'll drop the issue from my work ... Otherwise we can collaborate as I already have some code for this. Let me know. Was hoping to have this done in the next week or so.
I would love to collaborate, especially if you already have some code. But if you want to drop this from your work, I don't mind taking it on full time either. I can pick up from where ever you left off.
ok, if youve got full bandwidth go for it. if make progress on it this wk ill just drop it . I actually dont know where my old branch is for this :), so i guess youll have to start from scratch. One thing to note ~ Might be seeing if any tests can be reused for this or extended in a simple way by just adding a secondary service, rather then writing a full blown test from scratch. Let me know how it goes thanks !
I will let you know how it progresses. Thanks !
thanks for getting this taken care of :) looks like the PR is LGTM.
Thanks for letting me take a stab at it!
Change:
import ( "fmt" <del> "reflect" </del> "runtime/debug" "testing" "time"

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: There are too many pdb update operations compared with other resources. ! That is, there are many "Put" operations for pdb periodically in kube-apiserver log. In my view, the amount of pdb operations is connected with disruption controller's resyncPeriod and pdb's quantity in cluster. For example: disruption-controlle's default resyncPeriod is 30s, and there are 100 pdbs in cluster. We can find that the update operation times per minute is about 200. The data is reasonable, explanation is as follows: According to disruption-controlle's design, there is one resync every 30s. One resync means to call updatePdbStatus function for every pdb, so there are 200 times updatePdbStatus. Function updatePdbStatus judges whether the pdb is changed. If changed, call apiserver to update the pdb' status. When no eviction happens, disruptedPods is empty. In this situation, disruptedPods is an empty map, but pdb.Status.DisruptedPods is nil, empty map is not equal to nil. So reflect.DeepEqual(pdb.Status.DisruptedPods, disruptedPods) returns false. The pdb is thought to has be changed, then apiserver is called to update the pdb' status. In fact, there is no change for the pdb when disruptedPods is an empty map and pdb.Status.DisruptedPods is nil. What you expected to happen: There shouldn't be so many pdb update operations. That is, when pdb has no change, apiserver shouldn't be called to update its status. How to reproduce it (as minimally and precisely as possible): Create some pdbs in cluster, you will see many "Put" operations for pdb periodically in kube-apiserver log. Anything else we need to know?: Environment: kubernetes v1.13.2 Fix suggestions: The bug is caused by the mixed usage of empty and nil for disruptedPods, the type of which is map[string]metav1.Time.

There are two fix suggestions for it: one of empty map and nil for disruptedPods, use it consistently and refuse to mix empty map and nil. For example, when disruptedPods is empty or nil, save it as an empty map in etcd. Then every client gets pdb from etcd, the pdb.Status.DisruptedPods is an empty map. get pdb for etcd, assign an empty map to it if pdb.Status.DisruptedPods is nil. Maybe the mixed usage of empty and nil for map is a common problem in k8s design, not just for disruptedPods. I will propose a work around solution for the problem. If the solution has any problem, please let me know and I can modify the code.
/sig apps
/assign Morten can you PTAL and the open PR. I reviewed as well.
ref
Change:
}, }, } <ins> pvcConfig := e2epv.PersistentVolumeClaimConfig{ StorageClassName: &ns, } </ins> numPVs, numPVCs := 1, 1 pvols, claims, err = e2epv.CreatePVsPVCs(ctx, numPVs, numPVCs, c, f.Timeouts, ns, pvHostPathConfig, pvcConfig)

Discussion:
master-informing: ! Last 2 runs failed consecutively, first failure: No response /sig storage
/cc
I will take a look this week.
/triage accepted
/assign
Change:
// Network plugin settings. Shared by both docker and rkt. fs.StringVar(&s.NetworkPluginName, "network-plugin", s.NetworkPluginName, "<Warning: Alpha feature> The name of the network plugin to be invoked for various events in kubelet/pod lifecycle") <ins> //TODO(#46410): Remove the network-plugin-dir flag. </ins> fs.StringVar(&s.NetworkPluginDir, "network-plugin-dir", s.NetworkPluginDir, "<Warning: Alpha feature> The full path of the directory in which to search for network plugins or CNI config") <ins> fs.MarkDeprecated("network-plugin-dir", "Use --cni-bin-dir instead. This flag will be removed in a future version.") </ins> fs.StringVar(&s.CNIConfDir, "cni-conf-dir", s.CNIConfDir, "<Warning: Alpha feature> The full path of the directory in which to search for CNI config files. Default: /etc/cni/net.d") fs.StringVar(&s.CNIBinDir, "cni-bin-dir", s.CNIBinDir, "<Warning: Alpha feature> The full path of the directory in which to search for CNI plugin binaries. Default: /opt/cni/bin") fs.Int32Var(&s.NetworkPluginMTU, "network-plugin-mtu", s.NetworkPluginMTU, "<Warning: Alpha feature> The MTU to be passed to the network plugin, to override the default. Set to 0 to use the default 1460 MTU.")

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: bare-metal OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-controller-p1 4.4.0-53-generic ~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: chef cookbook Others: Docker 1.12.6, calico 2.1 CNI binaries: kubelet config: What happened: When trying to run pod error message is generated: So it seems that kubelet is trying to find CNI binaries in paths: /opt/loopback/bin /etc/cni/net.d /opt/calico/bin But it should look at since this is the default valur for parameter. What you expected to happen: Pod starts. How to reproduce it (as minimally and precisely as possible): Run pod: with kubelet 1.6 and CNI binaries in those path (default for calico): Anything else we need to know: After copy to and pod starts fine.
Good, very helpful to me
When set and not set , default path of CNI binaries will not take effect, the path specified by will be used instead. We should use and instead of if use CNI plugin.
I will push a PR to deprecate the flag. It is confusing. Closing this issue.
Was that ? It was closed without merging. I agree should be deprecated.
I think is needed before is removed. The flag is still not deprecated, I will send a PR to deprecate it.