jiebi/CodeConvo huggingface dataset:
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: On 1.8+ kubelet with --cpu-manager-policy=static, there is a constant stream of logging every 10 seconds or so in the following formats: for every pod, and for every privileged pod where update would fail but looks expected. What you expected to happen: First set of logs should probably be suppressed or to the debug level. Second set of logs should probably be better at distinguish expected case vs. unexpected case before logging that as errors. How to reproduce it (as minimally and precisely as possible): Run kubelet with , and watch /var/log/messages or similar. Anything else we need to know?: Environment: Kubernetes version (use ): 1.8.1 Cloud provider or hardware configuration: baremetal/onprem OS (e.g. from /etc/os-release): CentOS 7.4.1708 Kernel (e.g. ): 4.13.8- Install tools: custom Others:
/sig node
/cc
Thanks for filing this bug. Do you plan to work on fixing it too, or should we find someone to pick it up?
I can take a look and see what I can or cannot do with this.
"updating container" log line should be easy to deal with, it is doing a logging without setting a level, and if there is a convention on what should be the level of this type of logging (and similar in this file), I can submit a PR to add .V(x). support for it. Any preference on how the logging level should be handled?
I can help review . For the second part, it might be related to we left for ourselves in the CPU manager code. We should fetch the current resource config and only update the field.
volunteered to look into the second half of this.
Great. Regarding the second half, the best I can find so far indicates that the error is the result of attempting to modifying when the cgroup already has children. I will dig more also just to confirm.
Here is what I found:
Any update on the second part? Is it also fixed? Thanks.
This hasn't been fixed AFAIK. This error is only related to kube-proxy containers.
has there this issue related with kube-proxy been a solution, or it been ignorable?

Discussion:
continue } <del> glog.Infof("[cpumanager] reconcileState: updating container (pod: %s, container: %s, container id: %s, cpuset: "%v")", pod.Name, container.Name, containerID, cset) </del> <ins> glog.V(4).Infof("[cpumanager] reconcileState: updating container (pod: %s, container: %s, container id: %s, cpuset: "%v")", pod.Name, container.Name, containerID, cset) </ins> err = m.updateContainerCPUSet(containerID, cset) if err != nil { glog.Errorf("[cpumanager] reconcileState: failed to update container (pod: %s, container: %s, container id: %s, cpuset: "%v", error: %v)", pod.Name, container.Name, containerID, cset, err)
Change:
Is this a BUG REPORT or FEATURE REQUEST?: feature request What happened: As far, GPU and hugepages are particular resources which reqiure limits must equal to requests. But this rule may be broken when creating LimitRange, LimitRange with different values in default and defaultRequest can be created successfully, which would cause error in creating pods afterwards. We should not leave this error to pod creation but tell the users when creating the LimitRange. What you expected to happen: Validate if values are proper for GPU and hugepages when creating LimitRange. How to reproduce it (as minimally and precisely as possible): LimitRange with the following yaml: pods with the following yaml: would prompt error like: maybe we should let this error happen in creating LimitRange. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.1.1879+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-01T07:53:05Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.1.1879+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-01T07:50:07Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: bare metal OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others: /cc would this a possible feature?
/sig node
I have committed PR fixing this issue, please check when you are free :)

Discussion:
allErrs = append(allErrs, field.Invalid(idxPath.Child("maxLimitRequestRatio").Key(string(k)), maxRatio, fmt.Sprintf("ratio %s is greater than max/min = %f", maxRatio.String(), maxRatioLimit))) } } <ins> // for GPU and hugepages, the default value and defaultRequest value must match if both are specified if !helper.IsOvercommitAllowed(api.ResourceName(k)) && defaultQuantityFound && defaultRequestQuantityFound && defaultQuantity.Cmp(defaultRequestQuantity) != 0 { allErrs = append(allErrs, field.Invalid(idxPath.Child("defaultRequest").Key(string(k)), defaultRequestQuantity, fmt.Sprintf("default value %s must equal to defaultRequest value %s in %s", defaultQuantity.String(), defaultRequestQuantity.String(), k))) } </ins> } }
Change:
the new hyperkube image has changed without notifying the bash environment now links to sh, there is only one thing worst than an error, and it is a SILENT ERROR this means that anyone that execute kubectl inside the hyperkube and leverage from a bash environment now get the weirdest exceptions , in my case troubles where caused by flexvolume scripted in bash which stopped working without reason and with weird errors logged ( but also there are some other cluster-images based on your hyperkube image, and if you link bash to sh it will spread headache around :) ) while for version 1.7.7 the result was different so , or remove bash, or repristinate bash, link bash-sh is a NO-NO
/assign /sig node

Discussion:
FROM BASEIMAGE <ins> RUN echo CACHEBUST>/dev/null && clean-install  bash </ins> # The samba-common, cifs-utils, and nfs-common packages depend on <del> # ucf, which itself depends on /bin/bash existing. # It doesn't seem to actually need bash, however. RUN ln -s /bin/sh /bin/bash </del> <ins> # ucf, which itself depends on /bin/bash. RUN echo "dash dash/sh boolean false" | debconf-set-selections RUN DEBIAN_FRONTEND=noninteractive dpkg-reconfigure dash </ins> RUN echo CACHEBUST>/dev/null && clean-install  ca-certificates 

REGISTRY?=gcr.io/google-containers IMAGE?=debian-hyperkube-base <del> TAG=0.7 </del> <ins> TAG=0.8 </ins> ARCH?=amd64 CACHEBUST?=1

docker_pull( name = "debian-hyperkube-base-amd64", <del> digest = "sha256:1a05a58432254268c31ef5c8d9c21f3d01a40611b14707de6ac2772c0793bd13", </del> <ins> digest = "sha256:fc1b461367730660ac5a40c1eb2d1b23221829acf8a892981c12361383b3742b", </ins> registry = "gcr.io", repository = "google-containers/debian-hyperkube-base-amd64", <del> tag = "0.7",  # ignored, but kept here for documentation </del> <ins> tag = "0.8",  # ignored, but kept here for documentation </ins> ) docker_pull(

ARCH?=amd64 HYPERKUBE_BIN?=_output/dockerized/bin/linux/$(ARCH)/hyperkube <del> BASEIMAGE=gcr.io/google-containers/debian-hyperkube-base-$(ARCH):0.7 </del> <ins> BASEIMAGE=gcr.io/google-containers/debian-hyperkube-base-$(ARCH):0.8 </ins> TEMP_DIR:=$(shell mktemp -d -t hyperkubeXXXXXX) all: build
Change:
/kind bug What happened: logs when container is gone, should only log when we return an error
/sig node

Discussion:
} } if err := ds.client.StopContainer(podSandboxID, defaultSandboxGracePeriod); err != nil { <del> glog.Errorf("Failed to stop sandbox %q: %v", podSandboxID, err) </del> // Do not return error if the container does not exist if !libdocker.IsContainerNotFoundError(err) { <ins> glog.Errorf("Failed to stop sandbox %q: %v", podSandboxID, err) </ins> errList = append(errList, err) } }
Change:
/kind bug What happened: the kubelet keeps attempting to gc containers from dockershim checkpoint files. if the container is no longer present, we keep attempting to gc it because the file is never removed from checkpoint. What you expected to happen: checkpoint should not leak.
/sig node

Discussion:
// Do not return error if the container does not exist if !libdocker.IsContainerNotFoundError(err) { errList = append(errList, err) <ins> } else { // remove the checkpoint for any sandbox that is not found in the runtime ds.checkpointHandler.RemoveCheckpoint(podSandboxID) </ins> } } return utilerrors.NewAggregate(errList)
Change:
/kind bug cc What happened: Running one scheduling predicates conformance test on a 1.7.10 cluster where node names are FQDN, e.g. kube-node-, fails. What you expected to happen: The tests should pass. How to reproduce it (as minimally and precisely as possible): Follow or bootstrap a Kubernetes cluster where nodes names are FQDN, e.g. my-node- Anything else we need to know?: Also affects master but not 1.8.x. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GCP OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others: none
Cherry-pick for 1.7.x Again, it doesn't seem to affect 1.8.x.

Discussion:
for nodeName, cpu := range nodeToAllocatableMap { requestedCPU := cpu * 7 / 10 fillerPods = append(fillerPods, createPausePod(f, pausePodConfig{ <del> Name: "filler-pod-" + nodeName, </del> <ins> Name: "filler-pod-" + string(uuid.NewUUID()), </ins> Resources: &v1.ResourceRequirements{ Limits: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(requestedCPU, "DecimalSI"),
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig aws What happened: Every few seconds I get spam in my logs about "Could not determine public DNS from AWS metadata" from every node. This is really very spammy. What you expected to happen: No spam. How to reproduce it (as minimally and precisely as possible): Launch a private topology cluster with kops. Anything else we need to know?: There will never be a public-hostname in the metadata for private topology clusters. This line: Should be glog.V(4) i suspect, like line 1033 above it. Environment: Kubernetes version (use ): 1.7.4 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Jessie Kernel (e.g. ): 4.4.78-k8s Install tools: kops Others:
fixed in . PTAL. Thanks!
Thanks On a side note the metadata should probably be cached to stop thrashing the API but I don't know enough to be sure.
/cc

Discussion:
if err != nil || len(internalDNS) == 0 { //TODO: It would be nice to be able to determine the reason for the failure, // but the AWS client masks all failures with the same error description. <del> glog.V(2).Info("Could not determine private DNS from AWS metadata.") </del> <ins> glog.V(4).Info("Could not determine private DNS from AWS metadata.") </ins> } else { addresses = append(addresses, v1.NodeAddress{Type: v1.NodeInternalDNS, Address: internalDNS}) }

if err != nil || len(externalDNS) == 0 { //TODO: It would be nice to be able to determine the reason for the failure, // but the AWS client masks all failures with the same error description. <del> glog.V(2).Info("Could not determine public DNS from AWS metadata.") </del> <ins> glog.V(4).Info("Could not determine public DNS from AWS metadata.") </ins> } else { addresses = append(addresses, v1.NodeAddress{Type: v1.NodeExternalDNS, Address: externalDNS}) }
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I deployed a spec using an AzureDisk that triggered an "invalid memory address or nil pointer dereference". The deployment was initializing a pod and mounting an AzureDisk volume after downloading the container. Here are the kubelet logs on the node during the time the error was thrown: The line that throw the exception was , which accesses when the likely returned nil (in this ). What you expected to happen: An error message related to failed disk mounting is returned instead of a nil pointer deference. How to reproduce it (as minimally and precisely as possible): Not very easy to reproduce, but we were in the process of moving pods between nodes running 1.5 -1.8. We suspect there may have been unexpected interactions that caused both and to be missing when the AzureDisk is fetched. Our pod spec uses AzureDisk volumes, not PersistentVolumes. Anything else we need to know?: I'd expect to not access if an error was propagated up. We worked around this issue by deleting the deployment and re-applying our spec, which did the trick, probably since the application of the config took place in an entirely 1.8 setting rather than a hybrid cluster (1.5 and 1.8 worker nodes). Environment: Kubernetes version (use ): kubelet 1.8.1 & master running 1.8.1 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): CoreOS 1548.4.0 Kernel (e.g. ): Linux master 4.13.9-coreos SMP Thu Oct 26 03:35:38 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools: Others:
Hello Issue reported should be from while should be is nil, equals Maybe should we print this error into log ? Thanks very much !
Make sense.
/sig azure
thanks for the reporting, this issue is duplicate of which is fixed by and the fix is also in v1.8 now, while it's not in v1.8.1, line 48 in v1.8.1 is

Discussion:
func (m *azureDiskMounter) GetAttributes() volume.Attributes { readOnly := false volumeSource, err := getVolumeSource(m.spec) <del> if err != nil && volumeSource.ReadOnly != nil { </del> <ins> if err != nil { glog.Infof("azureDisk - mounter failed to get volume source for spec %s %v", m.spec.Name(), err) } else if volumeSource.ReadOnly != nil { </ins> readOnly = *volumeSource.ReadOnly } return volume.Attributes{
Change:
In , we merged a work around for heapster panic We should get rid of the work around after heapster version is updated. /cc /cc
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 /remove-lifecycle stale
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

Discussion:
"//pkg/kubelet/types:go_default_library", "//pkg/volume:go_default_library", "//vendor/github.com/golang/glog:go_default_library", <del> "//vendor/github.com/golang/protobuf/proto:go_default_library", </del> "//vendor/github.com/google/cadvisor/fs:go_default_library", "//vendor/github.com/google/cadvisor/info/v1:go_default_library", "//vendor/github.com/google/cadvisor/info/v2:go_default_library",

"time" "github.com/golang/glog" <del> "github.com/golang/protobuf/proto" </del> cadvisorfs "github.com/google/cadvisor/fs" cadvisorapiv2 "github.com/google/cadvisor/info/v2"

Name: stats.Attributes.Metadata.Name, // The StartTime in the summary API is the container creation time. StartTime: metav1.NewTime(time.Unix(0, container.CreatedAt)), <del> // Work around heapster bug. https://github.com/kubernetes/kubernetes/issues/54962 // TODO(random-liu): Remove this after heapster is updated to newer than 1.5.0-beta.0. CPU: &statsapi.CPUStats{ UsageNanoCores: proto.Uint64(0), }, Memory: &statsapi.MemoryStats{ RSSBytes: proto.Uint64(0), }, Rootfs: &statsapi.FsStats{}, </del> <ins> CPU:       &statsapi.CPUStats{}, Memory:    &statsapi.MemoryStats{}, Rootfs:    &statsapi.FsStats{}, </ins> // UserDefinedMetrics is not supported by CRI. } if stats.Cpu != nil {
Change:
Currently CPU consumption is not capped, which can be problematic in some setups
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
/remove-lifecycle stale This is still relevant. If k8s back plane cluster components on the nodes are not resource constrained, user workload deployed to those nodes have zero guarantees and can make no assumptions regarding available resources while they are executing. Mick's ticket is definitely something that warrants fixing, since we've been affected by this precise limitation ourselves in production.
GitHub didn't allow me to assign the following users: frapposelli. Note that only and repo collaborators 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

Discussion:
value: 100m - name: MEMORY_REQUEST value: 200Mi <ins> - name: CPU_LIMIT value: 300m </ins> - name: MEMORY_LIMIT <del> value: 300Mi </del> <ins> value: 500Mi </ins>
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I created a service (type LoadBalancer) on a 1.8.3 cluster. What you expected to happen: A load balancer to be deployed to GCP How to reproduce it (as minimally and precisely as possible): On a v1.8.3 cluster with GCP integration, deploy a service type LoadBalancer. The controller-manager was started with . However, was not specified. Example service: Anything else we need to know?: Stack trace captured in gist: Environment: Kubernetes version (use ): v1.8.3 Cloud provider or hardware configuration: GCP OS (e.g. from /etc/os-release): Ubuntu16 Kernel (e.g. ): 4.10.0-38-generic Install tools: Kubernetes-the-hard-way Others:
/sig gcp

Discussion:
cloudConfig.TokenSource = google.ComputeTokenSource("") cloudConfig.UseMetadataServer = true <ins> featureMap := make(map[string]bool) cloudConfig.AlphaFeatureGate = &AlphaFeatureGate{featureMap} </ins> if configFile != nil { if configFile.Global.ApiEndpoint != "" { cloudConfig.ApiEndpoint = configFile.Global.ApiEndpoint
Change:
What happened: I want to use kubeadm config file to extra altnames to use for the API Server serving cert, as we know the --apiserver-cert-extra-sans flag in the command line. but it not worked... What you expected to happen: generate multiple apiserver serving cert using kubeadm config file. Beacause we define extra etcd cluster, so the command line not support.
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. See the and . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig area/kubeadm
I think you yaml is wrong. The right key is
still don't have extra ips...
this is the right way hehe

Discussion:
hostname := "valid-hostname" advertiseIP := "1.2.3.4" cfg := &kubeadmapi.MasterConfiguration{ <del> API:        kubeadmapi.API{AdvertiseAddress: advertiseIP}, Networking: kubeadmapi.Networking{ServiceSubnet: "10.96.0.0/12", DNSDomain: "cluster.local"}, NodeName:   hostname, </del> <ins> API:               kubeadmapi.API{AdvertiseAddress: advertiseIP}, Networking:        kubeadmapi.Networking{ServiceSubnet: "10.96.0.0/12", DNSDomain: "cluster.local"}, NodeName:          hostname, APIServerCertSANs: []string{"10.1.245.94", "10.1.245.95"}, </ins> } altNames, err := getAltNames(cfg)

} } <del> expectedIPAddresses := []string{"10.96.0.1", advertiseIP} </del> <ins> expectedIPAddresses := []string{"10.96.0.1", advertiseIP, "10.1.245.94", "10.1.245.95"} </ins> for _, IPAddress := range expectedIPAddresses { found := false for _, val := range altNames.IPs {
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: https://k8s- What you expected to happen: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig testing /area build-release
A lot of tests in are very flaky. From and , and are the top 3 flaky tests among all kubernetes tests. /assign
fix double close channel panic related to https://k8s-
Is this issue ready to be closed? Did that PR fix the reason for flakes in all these tests?
This is still a problem, these tests are still the flakiest https://k8s-
My fix is double close channel panic. This one is not fixed. May be I shoud edit the title.
we also need a new issue then, I'm a bit overloaded ATM could one of open a new one with the garbagecollector failures?
OK
I'll try to debug some of these.
I created a new issue
Thanks!

Discussion:
close(monitor.stopCh) } } <ins> // reset monitors so that the graph builder can be safely re-run/synced. gb.monitors = nil </ins> glog.Infof("stopped %d of %d monitors", stopped, len(monitors)) }
Change:
See:
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
For some reason GitHub didn't close this automatically when the referencing PR merged.

Discussion:
// The Kubelet will look in this directory for an init configuration. // The path may be absolute or relative; relative paths are under the Kubelet's current working directory. // Omit this flag to use the combination of built-in default configuration values and flags. <del> // To use this flag, the DynamicKubeletConfig feature gate must be enabled. </del> <ins> // To use this flag, the KubeletConfigFile feature gate must be enabled. </ins> InitConfigDir flag.StringFlag // EXPERIMENTAL FLAGS

if f.DynamicConfigDir.Provided() && !utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) { return fmt.Errorf("the DynamicKubeletConfig feature gate must be enabled in order to use the --dynamic-config-dir flag") } <del> // ensure that nobody sets InitConfigDir if the dynamic config feature gate is turned off </del> <ins> // ensure that nobody sets InitConfigDir if the KubeletConfigFile feature gate is turned off </ins> if f.InitConfigDir.Provided() && !utilfeature.DefaultFeatureGate.Enabled(features.KubeletConfigFile) { return fmt.Errorf("the KubeletConfigFile feature gate must be enabled in order to use the --init-config-dir flag") }

fs.StringVar(&f.RootDirectory, "root-dir", f.RootDirectory, "Directory path for managing kubelet files (volume mounts,etc).") fs.Var(&f.DynamicConfigDir, "dynamic-config-dir", "The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. Presently, you must also enable the DynamicKubeletConfig feature gate to pass this flag.") <del> fs.Var(&f.InitConfigDir, "init-config-dir", "The Kubelet will look in this directory for the init configuration. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Omit this argument to use the built-in default configuration values. Presently, you must also enable the DynamicKubeletConfig feature gate to pass this flag.") </del> <ins> fs.Var(&f.InitConfigDir, "init-config-dir", "The Kubelet will look in this directory for the init configuration. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Omit this argument to use the built-in default configuration values. Presently, you must also enable the KubeletConfigFile feature gate to pass this flag.") </ins> // EXPERIMENTAL FLAGS fs.StringVar(&f.ExperimentalMounterPath, "experimental-mounter-path", f.ExperimentalMounterPath, "[Experimental] Path of mounter binary. Leave empty to use the default mount.")