jiebi/CodeConvo huggingface dataset:
Change:
const ( pollInterval                 = 1 * time.Second <del> podStatusUpdateTimeout       = 10 * time.Second </del> <ins> podStatusUpdateTimeout       = 30 * time.Second </ins> priorityClassesCreateTimeout = 10 * time.Second )

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted
/assign
This appears to be due to timeout being reached and the kubelet not updating the status of the terminated pod in time before the timeout is hit.
Testgrid: and
Change:
//     portion of the payload was deleted and is still present on disk. // //  4. The data in the current timestamped directory is compared to the projected <del> //     data to determine if an update is required. </del> <ins> //     data to determine if an update to data directory is required. </ins> // <del> //  5. A new timestamped dir is created. </del> <ins> //  5. A new timestamped dir is created if an update is required. </ins> // //  6. The payload is written to the new timestamped directory. //

Discussion:
When kubelet is creating configmap volume for a pod, it finished writing dir and made symlink to . At the same time, the kubelet is restarted, unfortunately the configmap item symlink is not created. The restarted kubelet will try to configmap, . Kubelet should create absent symlink for configmap volume. can hack kubelet to help reproduce it: sleep some time before ` kubelet and start official kubelet will skip to create symlink for UserVisibleFiles No response_ <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig node
/sig storage This seems like an issue for sig storage. Can someone take a look and confirm?
Can you please add the version details as well?
/remove-sig node
/assign
Change:
return fmt.Errorf("unable to get logs for container %q in pod %q namespace %q: unable to find pod", containerName, name, namespace) } <del> podStatus, found := kl.statusManager.GetPodStatus(pod.UID) </del> <ins> podUID := pod.UID if mirrorPod, ok := kl.podManager.GetMirrorPodByPod(pod); ok { podUID = mirrorPod.UID } podStatus, found := kl.statusManager.GetPodStatus(podUID) </ins> if !found { return fmt.Errorf("failed to get status for pod %q in namespace %q", name, namespace) }

Discussion:
Trying to get logs fails saying : But desribing the pod shows Pod Status and Container State are both :
Not sure how severe this is for the case of fluentd since it in fact logs to /var/logs, not to stdout. But it seems like a bug.
This happens with another mirror pod I created, so it isn't just fluentd.
does not seem to be related to
Change:
}, }, { <ins> // Echo handler that returns the contents of Host in the body func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) w.Write([]byte(r.Host)) }, http.Header{ "Host": {"muffins.cupcakes.org"}, }, probe.Success, []string{ "muffins.cupcakes.org", }, }, { </ins> handleReq(FailureCode, "fail body"), nil, probe.Failure,

Discussion:
I noticed that httpHeaders were to the httpGet probe in to Sadly the httpHeaders addition to the httpGet probe does function correctly for all headers except the header. I think this must be to do with the way make a special case of the Host header . I have some code I used to debug the issue that I can share if needed.
Sigh, letting you set Host was the entire point of providing that option.
Does the host header work in probes now? I have been browsing the issues but can not tell, as I am having trouble with it in my setup.
my fix should be in kubernetes 1.2.3+ I found some code that exercises the issue... could you try this on your cluster I cannot reproduce in the environment I have to hand that is running k8s 1.7
Change:
"io/ioutil" "os" "path/filepath" <del> "regexp" </del> "strings" "time" "github.com/vmware/govmomi/vim25" "github.com/vmware/govmomi/vim25/mo" <ins> "github.com/vmware/govmomi/vim25/soap" "github.com/vmware/govmomi/vim25/types" </ins> "k8s.io/klog" "k8s.io/api/core/v1"

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: Provsioning a PVC using a storage class with vSphere as the cloud provider failed with error "runtime error: index out of range". What you expected to happen: The PVC should have been created. How to reproduce it (as minimally and precisely as possible): Create a PVC using a storage class with vSphere as the cloud provider and a VMware vCenter Server where the default language is not English. Anything else we need to know?: K8s in conjunction with vSphere PVC relies on English error messages from the VMware API in order to determine the canonical path for a newly created volume (VMDK file). The faulting code (v1.11.3, still the same on master) can be found here (starting at line 312): The line "canonicalVolumePath = match[1]" (340) in the above code is the problem because "File (.*?) was not found" (English) never matches for a different language (e.g. German: "Datei [DATASTORE] kubevols/kube- wurde nicht gefunden") and a “runtime error: index out of range” oocurs in the "kube-controller-manager". This causes the already created volume (VMDK file) not to be reported back to the K8s system which in turn will try to recreate it repeatedly in a loop (fails with "Cannot complete the operation because the file or folder [DATASTORE] /kubevols/kubernetes-dynamic-pvc-[UUID] already exists"). Find below the corresponding log excerpt (kube-controller-manager): Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): n/a Kernel (e.g. ): n/a Install tools: n/a Others: n/a <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
Change:
mkdir -p "${CONTAINERIZED_MOUNTER_HOME}/rootfs" local -r mounter_tar_sha="8003b798cf33c7f91320cd6ee5cec4fa22244571" download-or-bust "${mounter_tar_sha}" "https://storage.googleapis.com/kubernetes-release/gci-mounter/mounter.tar" <del> cp "${KUBE_HOME}/kube-manifests/gci-trusty/gci-mounter" "${CONTAINERIZED_MOUNTER_HOME}/mounter" </del> <ins> cp "${KUBE_HOME}/kube-manifests/kubernetes/gci-trusty/gci-mounter" "${CONTAINERIZED_MOUNTER_HOME}/mounter" </ins> chmod a+x "${CONTAINERIZED_MOUNTER_HOME}/mounter" mv "${KUBE_HOME}/mounter.tar" /tmp/mounter.tar tar xf /tmp/mounter.tar -C "${CONTAINERIZED_MOUNTER_HOME}/rootfs"

Discussion:
We suspect that caused the failures. /sig storage /kind bug
/assign
Fixed by
/assign
GitHub didn't allow me to assign the following users: humblec. Note that only can be assigned. <detailsIn response to : /assign 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:
go_library( name = "go_default_library", <del> srcs = ["volume_manager.go"], </del> <ins> srcs = [ "volume_manager.go", "volume_manager_fake.go", ], </ins> importpath = "k8s.io/kubernetes/pkg/kubelet/volumemanager", deps = [ "//pkg/kubelet/config:go_default_library",

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] CSI Volumes [Driver: csi-hostpath-v0] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow] [sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow] [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow] Since when has it been failing: 2019-01-15 (when they were ) Testgrid link: Reason for failure: They all seem to be failing with: The failures seem to start with .
/sig storage
Summoning and This seems to have been failing since it was in master-blocking.
This is the same as
Thanks closing this one. /close
Closing this issue. <detailsIn response to : Thanks closing this one. 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
/reopen I took a look at the latest test failures and I think it is a different issue than
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
Looking at one test failure here: Sequence of events: stopped, pod deleted: started again: volume to dsw started and failed because it's not in the node's volumesinuse list. This repeats for a while. also started, but we skipped cleaning up because the volume is in dsw so we want to let volume manager gracefully cleanup don't remove volume from dsw because actual state has not been updated? So it seems like there's a problem with populating the node's volumesinuse after a kubelet restart.
cc
/assign will continue investigating.

i will try repro-ing at without different commits to try to figure out which pr introduced the regression
/priority important-soon
I ran these tests against a cluster with the NodeLease feature disabled, and the tests pass. So I think the issue is related to the new NodeLease feature enabled a month ago: cc
I discussed with VolumesInUse is updated periodically in the Node.Status. So we need to make sure this flow is working well with the NodeLease feature.
and I walked through the code. The NodeLease feature introduced an early exit to the node status update function, so our theory is we need to add a call to . I will make the change and test it out
Change:
s.livezRegistry.installHandler(s.Handler.NonGoRestfulMux) } <del> // shutdownCheck fails if the embedded channel is closed. This is intended to allow for graceful shutdown sequences // for the apiserver. type shutdownCheck struct { StopCh <-chan struct{} } func (shutdownCheck) Name() string { return "shutdown" } func (c shutdownCheck) Check(req *http.Request) error { select { case <-c.StopCh: return fmt.Errorf("process is shutting down") default: } return nil } </del> // delayedHealthCheck wraps a health check which will not fail until the explicitly defined delay has elapsed. This // is intended for use primarily for livez health checks. func delayedHealthCheck(check healthz.HealthChecker, clock clock.Clock, delay time.Duration) healthz.HealthChecker {

Discussion:
Quoted from 's Splitting healthz/ into livez/ and readyz/
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
/cc
/sig scheduling
I read all the content of the PR comment and am willing to work on this issue Do we need to continue some discussion for this issue
Hi , thanks for offering your help. But I was working in progress before knowing you can work on this. However, please feel free to contribute the similar issue
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
return err } startTime := time.Now() <del> err = reaper.Stop(ns, name, 0, nil) </del> <ins> err = clientset.ExtensionsV1beta1().ReplicaSets(ns).Delete(name, &metav1.DeleteOptions{}) </ins> if apierrs.IsNotFound(err) { Logf("ReplicaSet %s was already deleted: %v", name, err) return nil

Discussion:
As the title said, we need update touse server side reaper. xref:
/sig apps
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/assign
Change:
docker_opts+=" --log-level=warn" fi local use_net_plugin="true" <del> if [[ "${NETWORK_PROVIDER:-}" != "kubenet" && "${NETWORK_PROVIDER:-}" != "cni" ]]; then </del> <ins> if [[ "${NETWORK_PROVIDER:-}" == "kubenet" || "${NETWORK_PROVIDER:-}" == "cni" ]]; then # set docker0 cidr to private ip address range to avoid conflict with cbr0 cidr range docker_opts+=" --bip=169.254.123.1/24" else </ins> use_net_plugin="false" docker_opts+=" --bridge=cbr0" fi

Discussion:
On a cluster using GCI, I'm not able to create docker containers using the docker CLI. On further introspection, it looks like bridge is being deleted. I consider this a regression. K8s used to allow creating docker containers out of band and in-fact it is a feature that is taken into account as part of k8s node features. To further exacerbate this issue, exists on containervm. We need to match the behavior between GCI and container-vm and ideally stop deleting docker0 bridge. cc
During GCI start up, got deleted to avoid overlapping cidr with . ref:
there's no need to delete docker0 afaik. It was deleted on gci master to fix the "overlapping cidr" problem, i.e we were supplying to kubelet on GKE master, and this resulted in 2 bridges with the same cidr. At the time I'd suggested passing the correct cidr. Don't remember where this discussion ended. Note that containers on docker0 with/without cni are broken anyway, we used to start docker with --bridge=cbr0, so would result in an ip from cbr0. This is no longer the case. We use kubenet to put containers on cbr0, so will result in an ip from docker0, which is not connected to nanything else.
This shouldn't cause docker crashes? you should still be able to create containers, just no networking. And networking is broken through docker CLI anyway because of the cni issue mentioned, or are you observing something different?
will return error. Have to add
Since bridge has been deleted, docker run by default will fail unless one overrides the network ns to be host or none.
so what we're really losing is the ability to docker run then talk to others (external internet, other pods) without net=host on GCI. This is useful and we should fix it, as mentioned earlier we probably don't need to delete docker0. docker run + others talking to us is broken because of the cni change, and will be broken even with docker0 (IMO this is fine).
cc
Yeah. I'd prefer ignoring docker0 as long as it doesn't affect kubelet functionality. , Prashanth B wrote:
Vish pointed out that of docker dies, docker0 comes back.

Given that we should be consistent. Either force docker not to create a bridge at all, EVER, or just ignore docker0. We may even want to consider assigning --bip= 169.254.123.0/24 or something, so we can reliably use 172.* for clusters eventually. , Vish Kannan wrote:
Change:
for isomorphicKey, event := range e.eventCache { if event.Series != nil { if recordedEvent, retry := recordEvent(e.sink, event); !retry { <del> e.eventCache[isomorphicKey] = recordedEvent </del> <ins> if recordedEvent != nil { e.eventCache[isomorphicKey] = recordedEvent } </ins> } } }

Discussion:
What happened: kube-scheduler panics when client-go tries to finish the existing event series, see: What you expected to happen: kube-scheduler should not panic How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority critical-urgent /sig scheduling
Change:
dc.sync(ctx, pdbName) ps.VerifyDisruptionAllowed(t, pdbName, 0) <del> verifyUnsupportedControllerEventEmitted(t, dc) </del> <ins> verifyEventEmitted(t, dc, "UnmanagedPods") } // Create a pod  with unsupported controller, and verify that a PDB with a percentage // specified won't allow a disruption. func TestUnsupportedControllerPod(t *testing.T) { dc, ps := newFakeDisruptionController() pdb, pdbName := newMinAvailablePodDisruptionBudget(t, intstr.FromString("28%")) add(t, dc.pdbStore, pdb) ctx := context.TODO() dc.sync(ctx, pdbName) // This verifies that when a PDB has 0 pods, disruptions are not allowed. ps.VerifyDisruptionAllowed(t, pdbName, 0) pod, _ := newPod(t, "naked") isController := true pod.OwnerReferences = append(pod.OwnerReferences, metav1.OwnerReference{ APIVersion: "apps.test.io/v1", Kind:       "TestWorkload", Name:       "fake-controller", UID:        "b7329742-8daa-493a-8881-6ca07139172b", Controller: &isController, }) add(t, dc.podStore, pod) dc.sync(ctx, pdbName) ps.VerifyDisruptionAllowed(t, pdbName, 0) verifyEventEmitted(t, dc, "CalculateExpectedPodCountFailed") </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:
metav1.NamespaceSystem, metav1.NamespaceDefault, metav1.NamespacePublic, <ins> corev1.NamespaceNodeLease, </ins> }) if err != nil { e2elog.Failf("Error deleting orphaned namespaces: %v", err)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which test(s) are failing: When is specified in kubetest, the is trying to delete all namespaces except , and (see ) With Kubernetes 1.14 the features was enabled which creates their lease objects in a separate namespace which could sometimes not be cleaned up correctly. () Since when has it been failing: Testgrid link: Reason for failure: The SetupSuite is trying to delete system namespace Anything else we need to know:
/sig testing
Change:
signalToResource[evictionapi.SignalNodeFsAvailable] = resourceNodeFs signalToResource[evictionapi.SignalNodeFsInodesFree] = resourceNodeFsInodes <del> resourceToSignal = map[v1.ResourceName]evictionapi.Signal{} for key, value := range signalToResource { resourceToSignal[value] = key } // Hard-code here to make sure resourceNodeFs maps to evictionapi.SignalNodeFsAvailable // (TODO) resourceToSignal is a map from resource name to a list of signals resourceToSignal[resourceNodeFs] = evictionapi.SignalNodeFsAvailable </del> <ins> // maps resource to signals (the following resource could be reclaimed) resourceClaimToSignal = map[v1.ResourceName][]evictionapi.Signal{} resourceClaimToSignal[resourceNodeFs] = []evictionapi.Signal{evictionapi.SignalNodeFsAvailable} resourceClaimToSignal[resourceImageFs] = []evictionapi.Signal{evictionapi.SignalImageFsAvailable} resourceClaimToSignal[resourceNodeFsInodes] = []evictionapi.Signal{evictionapi.SignalNodeFsInodesFree} resourceClaimToSignal[resourceImageFsInodes] = []evictionapi.Signal{evictionapi.SignalImageFsInodesFree} </ins> } // validSignal returns true if the signal is supported.

Discussion:
It is possible to have multiple signals that point to the same type of resource, e.g., both SignalNodeFsAvailable and SignalAllocatableNodeFsAvailable refer to the same resource NodeFs. Change the map from map[v1.ResourceName]evictionapi.Signal to map[v1.ResourceName][]evictionapi.Signal
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/kind cleanup /priority important/soon taking a guess at labels to satisfy the milestone munger
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node sig/storage: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/cleanup: Adding tests, refactoring, fixing old bugs. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Looks like the PR for this is just awaiting merge
Change:
if _, exists := lb.services[svcPort]; !exists { lb.services[svcPort] = &balancerState{affinity: *newAffinityPolicy(affinityType, ttlMinutes)} glog.V(4).Infof("LoadBalancerRR service %q did not exist, created", svcPort) <ins> } else if affinityType != "" { lb.services[svcPort].affinity.affinityType = affinityType </ins> } return lb.services[svcPort] }

Discussion:
!topic/google-containers/pjx13NWEFcg The bug seems to be in kube-proxy.
Change:
<ins> package client type ShardSpace struct { // required, must be unique within the database Name string `json:"name"` // required, a database has many shard spaces and a shard space belongs to a database Database string `json:"database"` // this is optional, if they don't set it, we'll set to /.*/ Regex string `json:"regex"` // this is optional, if they don't set it, it will default to the storage.dir in the config RetentionPolicy   string `json:"retentionPolicy"` ShardDuration     string `json:"shardDuration"` ReplicationFactor uint32 `json:"replicationFactor"` Split             uint32 `json:"split"` } </ins>

Discussion:
Due to changes in field selectors (see ) heapster was almost certainly busted, but continues to pass. This seems incorrect.