jiebi/CodeConvo huggingface dataset:
Change:
fakeDocker.ContainerList = []docker.APIContainers{ { // format is // k8s_<container-id>_<pod-fullname>_<pod-uid> <del> Names: []string{"/k8s_bar_foo_new_12345678_0"}, </del> <ins> Names: []string{"/k8s_bar1_foo1_new_12345678_0"}, </ins> ID:    "1234", }, <ins> { // format is // k8s_<container-id>_<pod-fullname>_<pod-uid> Names: []string{"/k8s_bar2_foo2_new_87654321_0"}, ID:    "5678", }, { // format is // k8s_<container-id>_<pod-fullname>_<pod-uid> Names: []string{"/k8s_POD_foo2_new_87654321_0"}, ID:    "8765", }, </ins> } kubelet.pods = []api.BoundPod{ { ObjectMeta: api.ObjectMeta{ UID:       "12345678", <del> Name:      "foo", </del> <ins> Name:      "foo1", </ins> Namespace: "new", }, Spec: api.PodSpec{ Containers: []api.Container{ <del> {Name: "bar"}, </del> <ins> {Name: "bar1"}, }, }, }, { ObjectMeta: api.ObjectMeta{ UID:       "87654321", Name:      "foo2", Namespace: "new", }, Spec: api.PodSpec{ Containers: []api.Container{ {Name: "bar2"}, </ins> }, }, }, } <del> waitGroup.Add(1) </del> <ins> waitGroup.Add(2) </ins> err := kubelet.SyncPods(kubelet.pods, emptyPodUIDs, time.Now()) if err != nil { t.Errorf("unexpected error: %v", err)

Discussion:
Observed in testing somehting unrelated - prio We need a test that captures this - we can't let this slip through, Maybe same as ?
I just reproduced this with newly built cluster from HEAD. This is definitely a regression introduced lately. Will look into it in detail.
Change:
- key: config path: ip-masq-agent tolerations: <ins> - effect: NoSchedule operator: Exists - effect: NoExecute operator: Exists </ins> - key: "CriticalAddonsOnly" operator: "Exists"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: ip-masq-agent should be scheduled on all the nodes and has the same toleration as the deamon set . See the difference: What you expected to happen: ip-masq-agent tolerate NoSchedule and NoExecute so that it will be scheduled in all nodes. How to reproduce it (as minimally and precisely as possible): Create a node with taint operation=NoSchedule. ip-masq-agent will not be scheduled in that node. Anything else we need to know?: I don't believe this is intended behavior. But if it is, let me know and I will close this issue. Environment: Kubernetes version (use ): HEAD /assign /assign /assign
/sig cluster-lifecycle
Change:
<ins> /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package schema import ( "testing" ) // TestStructuralUnfoldNilValueValidation tests that Unfold() does not crash // on a IntOrString pattern with nil ValueValidation. func TestStructuralUnfoldIntOrString(t *testing.T) { schema := Structural{ Extensions: Extensions{ XIntOrString: true, }, } schema.Unfold() } </ins>

Discussion:
What happened: API server panics handling requests for a CRD with OpenAPI validation with What you expected to happen: CRD is applied successfully. How to reproduce it (as minimally and precisely as possible): kind create cluster --image kindest/node:v1.16.1 then kubectl apply: Partial logs from API server: Anything else we need to know?: Environment: Kind Kubernetes version (use ):OS (e.g: ):
/sig api-machinery
/cc
where It seems that s.AnyOf was referencing some invalid address.
yes, which is very strange, given s was dereferenced earlier in the same method: is investigating
reproduced and has a fix
I had the same issue with prometheus (kube 1.16.1). Deploying is fine but when trying to delete, it crashes the api server. For those who can't upgrade to 1.16.2+ (fixed version) there is a workaround : using etcd to delete the resources that crash the api server : here I grep on coreos because I know it is prometheus that crashes the api server Remove every item in the list that causes the crash :
Note this is also resolved in 1.15.5+ and 1.16.2+, upgrading to 1.17.x is not required to resolve this
Change:
var retryErr error err := wait.ExponentialBackoff(az.requestBackoff(), func() (bool, error) { machine, retryErr = az.getVirtualMachine(name) <ins> if retryErr == cloudprovider.InstanceNotFound { return true, cloudprovider.InstanceNotFound } </ins> if retryErr != nil { glog.Errorf("backoff: failure, will retry,err=%v", retryErr) return false, nil

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug /sig azure What happened: When performing a rolling update of my nodes (i.e., cordon, drain, delete VM on Azure side) one after the other the corresponding objects of the deleted VMs are not being deleted from etcd. This affects all patch versions while it is working fine with . What you expected to happen: The objects are removed from etcd when the backing virtual machine does not exist any more. How to reproduce it (as minimally and precisely as possible): Create a Kubernetes cluster with version on Azure, cordon and drain the node and delete the backing VM afterwards. Anything else we need to know?: No. Environment: Kubernetes version (use ): 1.9.X Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): CoreOS Stable 1632.3.0 Others: machine type
It requires some time for controller manager to detect the removed VM on Azure. Could you share the logs of kube-controller-manager?
Hi thank's for taking a a look. Well, sure, it may take some time, however, it's really fast for Kubernetes clusters on Azure with versions prior than and also for clusters on other cloud providers (even with ). I have waited more than 30 minutes, but the "old" objects are still there (which leads to a weird state/view on pods, etc.). I've seen this problem only with Azure . I just reproduced the problem: At this point in time the backing VMs for and are already gone/do not exist any more. The relevant logs of the kube-controller-manager:
Thanks of providing the information. I'm checking whether there is something wrong inside cloud provider
confirmed it's a bug in azure cloud provider
Thank you for investigating. Do you already know whether the fix will be backported or only part of 1.10?
By the way, have you configured backoff with azure cloud provider? what params have you configured?
This is the relevant part of the current cloud provider configuration: Does it look good to you?
There is a problem in backoff logic which results in retrying even the VM has already removed from Azure. With the params you set, the backoff timeout will be about 40 hours. I recommend setting a smaller cloudProviderBackoffDuration (ensure 1) since this is an exponential backoff.
Okay, thank's a lot!
Change:
// NOTE: It's not recommended to be used concurrently from multiple threads - // if first user takes the whole timeout, the second one will get 0 timeout // even though the first one may return something later. <del> type timeBudget struct { </del> <ins> type timeBudget interface { takeAvailable() time.Duration returnUnused(unused time.Duration) } type timeBudgetImpl struct { </ins> sync.Mutex budget time.Duration

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: bazel-test-master (periodic-kubernetes-bazel-test-master ) Which test(s) are flaking: gotest: Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --cc
/sig api-machinery
This is continuing to be flaky with more recent failure:
/assign Would you mind taking a look here? thanks! /triage accepted
- can we somehow uncover when this started happening? This test is very old and it seems it started happening very recently, so it would be helpful to see when this started happening...
Triage shows flakes starting ~Sept 30: Before Sept 30 it seems the job was flaking much less frequently.
Might be related to I will take a look.
It seems it's not related to that PR (neither to the previous: ) As there were already failures like that on Sep 24th (before this one was merged). I will take a deeper look.
OK - it's not related to any changes mentioned before. I can reproduce this particular failure by simply adding somewhere in this block: So it's probably connected to cpu-starvation at the test level and the solution is to switch to less aggressive timeouts. Will send out a PR.
Actually - it appeared to be slightly more subtle then that. But I already fully understand the problem. It's purely test issue, but require a bit more changes (and I won't get to it today/tomorrow). I will send a fix for that early next week.
- if that changes anything from your tracking perspective ^^
No board changes yet - the next stage is "Observing" once this issue gets closed :) If you have time - I'd love to pick your brain/understand the error more thoroughly though! Hoping you drop a good explanation in your PR next week
Thanks for sharing those insights, on your discovery of the solution to this bug.
It seems the PR didn't address that fully. Looking.
out for review
Change:
} else if config.SubnetworkName != "" { subnetURL = gceSubnetworkURL(config.ApiEndpoint, netProjID, config.Region, config.SubnetworkName) } else { <del> // Attempt to determine the subnetwork in case it's an automatic network. // Legacy networks will not have a subnetwork, so subnetworkURL should remain empty. </del> <ins> // Determine the type of network and attempt to discover the correct subnet for AUTO mode. // Gracefully fail because kubelet calls CreateGCECloud without any config, and minions // lack the proper credentials for API calls. </ins> if networkName := lastComponent(networkURL); networkName != "" { <del> if n, err := getNetwork(service, netProjID, networkName); err != nil { // Gracefully fail because kubelet calls CreateGCECloud without any config, and API calls will fail coming from minions. glog.Warningf("Could not retrieve network %q in attempt to determine if legacy network or see list of subnets, err %v", networkURL, err) </del> <ins> var n *compute.Network if n, err = getNetwork(service, netProjID, networkName); err != nil { glog.Warningf("Could not retrieve network %q; err: %v", networkName, err) </ins> } else { <del> // Legacy networks have a non-empty IPv4Range if len(n.IPv4Range) > 0 { glog.Infof("Determined network %q is type legacy", networkURL) </del> <ins> switch typeOfNetwork(n) { case netTypeLegacy: glog.Infof("Network %q is type legacy - no subnetwork", networkName) </ins> isLegacyNetwork = true <del> } else { // Try to find the subnet in the list of subnets subnetURL = findSubnetForRegion(n.Subnetworks, config.Region) if len(subnetURL) > 0 { glog.Infof("Using subnet %q within network %q & region %q because none was specified.", subnetURL, n.Name, config.Region) </del> <ins> case netTypeCustom: glog.Warningf("Network %q is type custom - cannot auto select a subnetwork", networkName) case netTypeAuto: subnetURL, err = determineSubnetURL(service, netProjID, networkName, config.Region) if err != nil { glog.Warningf("Could not determine subnetwork for network %q and region %v; err: %v", networkName, config.Region, err) </ins> } else { <del> glog.Warningf("Could not find any subnet in region %q within list %v.", config.Region, n.Subnetworks) </del> <ins> glog.Infof("Auto selecting subnetwork %q", subnetURL) </ins> } } }

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:
// If nodePort is specified, user should be able to use nodeIP:nodePort to reach the backend endpoints if svcInfo.nodePort > 0 { <ins> // If the preserve-destination service annotation is present, we will disable routing mesh for NodePort. // This means that health services can use Node Port without falsely getting results from a different node. nodePortEndpoints := hnsEndpoints if svcInfo.preserveDIP { nodePortEndpoints = hnsLocalEndpoints } </ins> hnsLoadBalancer, err := hns.getLoadBalancer( <del> hnsEndpoints, </del> <ins> nodePortEndpoints, </ins> loadBalancerFlags{localRoutedVIP: true}, sourceVip, "",

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: When preserve-destination annotation is set to true the routing mesh is getting disabled for actual traffic flow but the route mesh isn’t getting disabled for LB liveness probes. As a result the VM's which doesn't have active pods are looking healthy from the point of view of LB and getting active customer traffic. The VM's are dropping the traffic since the routing mesh is disabled. What you expected to happen: When preserve-destination annotation is set routing mesh should be disabled for LB liveness probes as well as end user traffic. How to reproduce it (as minimally and precisely as possible): Enable preserve-destination=true annotation in Azure k8s service and deploy an app that is registered with the service. Anything else we need to know?: Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: Azure (ACS) OS (e.g: ): Windows 1903 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Fixed by
Hey Yu-Ju this missed the 1.17 deadline and it’s a bug fix for the Windows preserve-destination feature. Can we back port this?
/sig node windows
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue.

<detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
Change:
Pid:                 1000, ProcessName:         "fakeProcess", TimeOfDeath:         time.Now(), <del> ContainerName:       recordEventContainerName, VictimContainerName: "some-container", </del> <ins> ContainerName:       recordEventContainerName + "some-container", VictimContainerName: recordEventContainerName, </ins> }, { Pid:                 1000, ProcessName:         "fakeProcess", TimeOfDeath:         time.Now(), <del> ContainerName:       "/dont-record-oom-event", VictimContainerName: "some-container", </del> <ins> ContainerName:       recordEventContainerName + "kubepods/some-container", VictimContainerName: recordEventContainerName + "kubepods", </ins> }, } numExpectedOomEvents := len(oomInstancesToStream) - numOomEventsWithIncorrectContainerName

Discussion:
What happened: A SystemOOM event was not reported even when the memory limit hit was the root cgroup memory limit. What you expected to happen: A SystemOOM event should have been reported. How to reproduce it (as minimally and precisely as possible): Do not set or , and set to disable memory eviction on the kubelet. Run a pod without memory limits which slowly consumes memory, such as with from Use arguments -mem-alloc-size", "100Mi", "-mem-alloc-sleep", "10s". This should trigger an OOM on the root cgroup, but no event will be generated. Anything else we need to know?: cAdvisor populates ContainerName and VictimContainerName from matching the regexp: instead in the kubelet. cc
/sig node /priority important-soon
Change:
} func (r *SimpleWatchReactor) Handles(action Action) bool { <del> resourceCovers := r.Resource == "*" || r.Resource == action.GetResource().Resource if !resourceCovers { return false } return true </del> <ins> return resourceCovers(r.Resource, action) </ins> } func (r *SimpleWatchReactor) React(action Action) (bool, watch.Interface, error) {

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 -- Can't match "serviceaccounts/token", can only match "serviceaccounts" Can match "serviceaccounts/token"
/kind feature
/sig testing
/assign
/triage accepted
Change:
case ${DEB_ARCH} in s390x|arm64|ppc64el) <del> sed -i '/debian-security/d' /etc/apt/sources.list ;; </del> <ins> # we have to use the archive mirrors. # See: https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html echo "deb http://archive.debian.org/debian/ jessie main contrib non-free" | tee /etc/apt/sources.list echo "deb-src http://archive.debian.org/debian/ jessie main contrib non-free" | tee -a /etc/apt/sources.list ;; </ins> esac exit 0

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: The image ` cannot be built anymore, since its mirrors has been archived. For more details, see: What you expected to happen: The image should be buildable. How to reproduce it (as minimally and precisely as possible): cd kubernetes/tests/images make all-container WHAT=jessie-dnsutils Anything else we need to know?: /sig testing /area conformance /priority important-soon Environment: N/A Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/assign
ref:
Change:
return o.writeConfigFile() } <del> proxyServer, err := NewProxyServer(o.config, o.CleanupAndExit, o.CleanupIPVS, o.scheme, o.master) </del> <ins> proxyServer, err := NewProxyServer(o) </ins> if err != nil { return err }

Discussion:
https://k8s- https://k8s- cc: /kind bug /priority failing-test
This is at least twice in a week we've had cross break due to a public method signature change not being brought to all platforms () We should do:
I'm lost - the PR in question adds an argument and fixes the call-site - what is broken?
Ahh, I see.
How did that PR get through, if it is so obviously broken on Cross?
Cross build doesn't run 100% of the time as a pre-submit (because it takes so long), and it can't block. It's something sig-testing is tracking, but there isn't a quick fix yet.
Looks like was skipped for that PR: "pull-kubernetes-cross Skipped" not sure why yet.
Cross runs when a file matching: changes, (which needs to be fixed, opening a test-infra issue to expand the regex), but also some files could have build tags without the file name matching () Additionally cross is not blocking (), the underlying bug should be fixed now though so once we get the fix in to k/k we can make it blocking when it does run.
I find has already sent a PR. Thanks!
Change:
return nil } <ins> func extractTransportname(ifaceOutput string) (iscsiTransport string) { re := regexp.MustCompile(`iface.transport_name = (.*)n`) rex_output := re.FindStringSubmatch(ifaceOutput) if rex_output != nil { iscsiTransport = rex_output[1] } else { return "" } // While iface.transport_name is a required parameter, handle it being unspecified anyways if iscsiTransport == "<empty>" { iscsiTransport = "tcp" } return iscsiTransport } </ins> func extractDeviceAndPrefix(mntPath string) (string, string, error) { ind := strings.LastIndex(mntPath, "/") if ind < 0 {

Discussion:
open-iscsi software initiators are currently broken for non- interfaces due to the fact that the devicePath (in ) is assumed to use the prefixing scheme for all interfaces not named . This causes waitForPathToExist to timeout after 10 seconds since the device path that it is waiting for is not the - prefixed path that is created, resulting in host logging such as: or K8S event logs such as: open-iscsi support for hardware transports was in the following commit: In this commit, software iSCSI support was assumed to be done through only the use of the default interface. According to the documentation at (Section 5.1.1) both software and offload/hardware interfaces are intended to be configured using named interface specifications and is only a backwards-compatibility vehicle. Configuration of cannot be done via the use of as this approach is specifically forbidden in the documentation: Leaving this here to help others associate various failure modes with this issue and possible resolution: In my case I am just learning and this is my first iSCSI deployment. My initial error was that I was receiving an message at discovery-time even though I had used to define a name. This approach failed because I didn't realize that iscsid needed to be bounced before it would pick up changes to that file. I had defined a custom specification and was using that to accomplish the task of setting my initiator name. I was able to unwind this mess and return to the use of once I read the code and understood what it was attempting to do.
i'm marking this as a feature request against the iscsi volume driver. RFE: support iscsi interfaces named something besides 'default'.
In theory the fix should be easy, just move the path check from iface name to transport_name. I will take a look asap, unfortunately I am travelling till monday
Sorry about the previous comment, I was logged in to the wrong account. In theory the fix should be easy, just move the path check from iface name to transport_name. I will take a look asap, unfortunately I am travelling till monday. can you share your iface file ? It will help me validate
I no longer have the file precisely as it was. However, I did have some version of what I had used committed into my VCS. While not 100% sure this is what I was using while encountering the failure it does looks to be about what I'd expect: