jiebi/CodeConvo huggingface dataset:
Change:
GCE PDs are allocated in chunks of GBs (not GiB) but function incorrectly creates volume in chunks of GiB - cc /sig storage
/kind bug
/assign
/priority important-soon
Hey I submit a pr for this issue. Your suggestions are very important. Thanks.

Discussion:
PersistentVolumeReclaimPolicy: c.options.PersistentVolumeReclaimPolicy, AccessModes:                   c.options.PVC.Spec.AccessModes, Capacity: v1.ResourceList{ <del> v1.ResourceName(v1.ResourceStorage): resource.MustParse(fmt.Sprintf("%dGi", sizeGB)), </del> <ins> v1.ResourceName(v1.ResourceStorage): resource.MustParse(fmt.Sprintf("%dG", sizeGB)), </ins> }, PersistentVolumeSource: v1.PersistentVolumeSource{ GCEPersistentDisk: &v1.GCEPersistentDiskVolumeSource{

} cap := persistentSpec.Spec.Capacity[v1.ResourceStorage] size := cap.Value() <del> if size != 100*1024*1024*1024 { </del> <ins> if size != 100*volume.GB { </ins> t.Errorf("Provision() returned unexpected volume size: %v", size) }

name := volume.GenerateVolumeName(c.options.ClusterName, c.options.PVName, 63) // GCE PD name can have up to 63 characters capacity := c.options.PVC.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)] <del> requestBytes := capacity.Value() // GCE works with gigabytes, convert to GiB with rounding up requestGB := volume.RoundUpSize(requestBytes, 1024*1024*1024) </del> <ins> // GCE PDs are allocated in chunks of GBs (not GiBs) requestGB := volume.RoundUpToGB(capacity) </ins> // Apply Parameters (case-insensitive). We leave validation of // the values to the cloud provider.

"type": "pd-ssd", "zone": cloudZone, }, <del> "1.5Gi", "2Gi", </del> <ins> "1.5G", "2G", </ins> func(volume *v1.PersistentVolume) error { return checkGCEPD(volume, "pd-ssd") },

map[string]string{ "type": "pd-standard", }, <del> "1.5Gi", "2Gi", </del> <ins> "1.5G", "2G", </ins> func(volume *v1.PersistentVolume) error { return checkGCEPD(volume, "pd-standard") },

map[string]string{ "type": "pd-standard", }, <del> "1Gi", "1Gi", </del> <ins> "1G", "1G", </ins> func(volume *v1.PersistentVolume) error { return checkGCEPD(volume, "pd-standard") },

name:        "unmanaged_zone", provisioner: "kubernetes.io/gce-pd", parameters:  map[string]string{"zone": unmanagedZone}, <del> claimSize:   "1Gi", </del> <ins> claimSize:   "1G", </ins> } sc := newStorageClass(test, ns, suffix) sc, err = c.StorageV1().StorageClasses().Create(sc)

claimSize:    "2Gi", expectedSize: "2Gi", } <ins> // gce or gke if getDefaultPluginName() == "kubernetes.io/gce-pd" { // using GB not GiB as e2e test unit since gce-pd returns GB, // or expectedSize may be greater than claimSize. test.claimSize = "2G" test.expectedSize = "2G" } </ins> claim := newClaim(test, ns, "default") testDynamicProvisioning(test, c, claim, nil) })
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Code inspection caused me to notice is installing downloading an ancient util-linux in order to build nsenter in a hard coded directory under /tmp. What you expected to happen: A more current version of util-linux would be download into a /tmp directory with a securely generated name. How to reproduce it (as minimally and precisely as possible): Read the section of marked "Install nsenter for ubuntu images". Anything else we need to know?: It's easy enough to use mktemp and download a newer util-linux and I have patches to do so. An alternative might be to do something like with nsenter via a container, but jpetazzo's container is also not actively curated and is using an old version of util-linux too. It's probably not appropriate to simply calculate the latest util-linux and download it, versus a specific one by version. But that means a steady stream of tweaks to update the version in use as new util-linux come out and are demonstrated to still be compatible. Would be a nice place to add CI as Trusty's LTS with a couple more years of support so this issue is unfortunately likely to hang around. Environment: OS (e.g. from /etc/os-release): Ubuntu Trusty Tahr
/sig testing
/assign

Discussion:
if [ $? -eq 0 ]; then if ! which nsenter > /dev/null; then echo "Do not find nsenter. Install it." <del> mkdir -p /tmp/nsenter-install cd /tmp/nsenter-install curl https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz | tar -zxf- </del> <ins> NSENTER_BUILD_DIR=$(mktemp -d /tmp/nsenter-build-XXXXXX) cd $NSENTER_BUILD_DIR curl https://www.kernel.org/pub/linux/utils/util-linux/v2.31/util-linux-2.31.tar.gz | tar -zxf- </ins> sudo apt-get update sudo apt-get --yes install make sudo apt-get --yes install gcc <del> cd util-linux-2.24 </del> <ins> cd util-linux-2.31 </ins> ./configure --without-ncurses make nsenter sudo cp nsenter /usr/local/bin <del> rm -rf /tmp/nsenter-install </del> <ins> rm -rf $NSENTER_BUILD_DIR </ins> fi fi
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: Test failed when running CPU Manager node e2e test on Ubuntu 16.04 locally, and show this panic message: What you expected to happen: Tests passed. How to reproduce it (as minimally and precisely as possible): Run this node e2e test, use the following command: Anything else we need to know?: I think this is because the following codes: is . I will send a PR to fix this after it is confirmed. /sig node /assign PTAL, Thanks!
Thanks for the bug report. Reproduced successfully. It looks like the response body may have changed from empty map to null, which caused this to break. In any case, suggested adding the fix to his pending PR here:
Hi, have fixed this, lgtm.

Discussion:
// The Kubelet panics if either kube-reserved or system-reserved is not set // when CPU Manager is enabled. Set cpu in kube-reserved > 0 so that // kubelet doesn't panic. <ins> if newCfg.KubeReserved == nil { newCfg.KubeReserved = map[string]string{} } </ins> if _, ok := newCfg.KubeReserved["cpu"]; !ok { newCfg.KubeReserved["cpu"] = "200m" }

var pod, pod1, pod2 *v1.Pod It("should assign CPUs as expected based on the Pod spec", func() { <del> oldCfg = enableCPUManagerInKubelet(f) </del> cpuCap, cpuAlloc, cpuRes = getLocalNodeCPUDetails(f) <del> // Skip CPU Manager tests if the number of allocatable CPUs < 1. if cpuAlloc < 1 { framework.Skipf("Skipping CPU Manager tests since the number of allocatable CPUs < 1") </del> <ins> // Skip CPU Manager tests altogether if the CPU capacity < 2. if cpuCap < 2 { framework.Skipf("Skipping CPU Manager tests since the CPU capacity < 2") </ins> } <ins> // Enable CPU Manager in the kubelet. oldCfg = enableCPUManagerInKubelet(f) </ins> By("running a non-Gu pod") ctnAttrs = []ctnAttribute{ {

waitForContainerRemoval(fmt.Sprintf("%s_%s", pod1.Spec.Containers[0].Name, pod1.Name)) waitForContainerRemoval(fmt.Sprintf("%s_%s", pod2.Spec.Containers[0].Name, pod2.Name)) <del> // Skip rest of the tests if the number of allocatable CPUs < 2. if cpuAlloc < 2 { framework.Skipf("Skipping rest of the CPU Manager tests since the number of allocatable CPUs < 2") </del> <ins> // Skip rest of the tests if CPU capacity < 3. if cpuCap < 3 { framework.Skipf("Skipping rest of the CPU Manager tests since CPU capacity < 3") </ins> } By("running a Gu pod requesting multiple CPUs")
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: --oidc-username-prefix option for api-server seems to not have any effect. The apiserver is running with --oidc-username-prefix=-, and if I'm changing ClusterRoleBinding username from prefix#username to username, I'm still getting: What you expected to happen: When using the "--oidc-username-prefix=-", the username should be "<user_id", without issuer prefix How to reproduce it (as minimally and precisely as possible): Follow the steps to set up the OIDC authentication, add "--oidc-username-prefix=-" to apiserver config file, restart kubelet, create client config for OIDC, try "kubeadm get nodes" Anything else we need to know?: I'm wondering if users are cached somewhere? Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-20T19:11:02Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-20T05:17:43Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: kubeadm OS (e.g. from /etc/os-release): centos 7.4
/sig auth
/assign
Re-opening for cherry pick.
The same issue is occurring with the flag.
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 2 days, the issue will be moved out of the v1.8 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Fix has been cherry picked. Fix will be available in v1.8.5 /close

Discussion:
ret.OIDCCAFile = s.OIDC.CAFile ret.OIDCClientID = s.OIDC.ClientID ret.OIDCGroupsClaim = s.OIDC.GroupsClaim <ins> ret.OIDCGroupsPrefix = s.OIDC.GroupsPrefix </ins> ret.OIDCIssuerURL = s.OIDC.IssuerURL ret.OIDCUsernameClaim = s.OIDC.UsernameClaim <ins> ret.OIDCUsernamePrefix = s.OIDC.UsernamePrefix </ins> } if s.PasswordFile != nil {
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: unit tests failed. What you expected to happen: How to reproduce it (as minimally and precisely as possible): It will get . I found this issue only happened when the is truely existent in the host, Anything else we need to know?: Environment: Kubernetes version (use kubectl version): head Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. uname -a): Install tools: Others: go version go1.9.2 linux/amd64
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
/area kubeadm

Discussion:
for _, rt := range tests { mounts := getHostPathVolumesForTheControlPlane(rt.cfg) <ins> // Avoid unit test errors when the flexvolume is mounted if _, ok := mounts.volumes[kubeadmconstants.KubeControllerManager][flexvolumeDirVolumeName]; ok { delete(mounts.volumes[kubeadmconstants.KubeControllerManager], flexvolumeDirVolumeName) } if _, ok := mounts.volumeMounts[kubeadmconstants.KubeControllerManager][flexvolumeDirVolumeName]; ok { delete(mounts.volumeMounts[kubeadmconstants.KubeControllerManager], flexvolumeDirVolumeName) } </ins> if !reflect.DeepEqual(mounts.volumes, rt.vol) { t.Errorf( "failed getHostPathVolumesForTheControlPlane:ntexpected: %vnt  actual: %v",
Change:
uses non existing etcd version for k8s 1.10.0. /kind bug /sig cluster-lifecycle

Discussion:
SupportedEtcdVersion = map[uint8]string{ 8:  "3.0.17", 9:  "3.1.10", <del> 10: "3.1.11", </del> <ins> 10: "3.1.10", </ins> } )

}, { kubernetesVersion: "1.10.0", <del> expectedVersion:   version.MustParseSemantic("3.1.11"), </del> <ins> expectedVersion:   version.MustParseSemantic("3.1.10"), </ins> expectedError:     nil, }, {

KubeVersion:    "v1.10.0-alpha.2", KubeadmVersion: "v1.10.0-alpha.2", DNSVersion:     "1.14.7", <del> EtcdVersion:    "3.1.11", </del> <ins> EtcdVersion:    "3.1.10", </ins> }, }, },
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: In case scheduler misses a node delete event, or cleaning the node from scheduler cache errors out, node will stay in scheduler cache forever and scheduler will try to schedule pods on it and keeps seeing an error similar to: E1123 00:00:00 7 ] Error scheduling namespace pod-1: node 'node-xyz' not found; retrying When scheduler sees these "not found" errors for a node, it should delete the node from its cache. In order to tolerate transient errors, it is better if it deletes the node when it keeps seeing this error multiple times and over some period of time. /sig scheduling
I can help fix it.
In all my Kubernetes controllers I back up watch handlers with a full scan every now and than to reconciliate as a safety net. I guess that would help with thess kind of errors as well. Thanks for looking into this.
Thanks for the suggestion. That sounds like a better approach. I think we should have periodic full scan to deal with similar scenarios. We should probably do it for all cached objects, not just nodes.
Sorry, I do not know that how we can do periodic full scan because seems has not function. and it consumes a lot of resources for doing periodic full scan also.
Okay, just removing the node from the cache - like you suggested - is then probably the most straightforward way to do it.
I also suspected that periodic resync would be prohibitively expensive, but I don't have any concrete numbers. If it is not acceptable, as said, we can stick to the first solution of removing the node when scheduler faces a "node not found" error. We should not remove the node right away. I'd suggest trying again to get the node and if the node is still not found, then remove it from the scheduler cache. Doing the same thing for Pods would be useful too, but that would be a separate PR.
Closing from merge of

Discussion:
} else { if _, ok := err.(*core.FitError); ok { glog.V(4).Infof("Unable to schedule %v %v: no fit: %v; waiting", pod.Namespace, pod.Name, err) <ins> } else if errors.IsNotFound(err) { if errStatus, ok := err.(errors.APIStatus); ok && errStatus.Status().Details.Kind == "node" { nodeName := errStatus.Status().Details.Name // when node is not found, We do not remove the node right away. Trying again to get // the node and if the node is still not found, then remove it from the scheduler cache. _, err := factory.client.CoreV1().Nodes().Get(nodeName, metav1.GetOptions{}) if err != nil && errors.IsNotFound(err) { node := v1.Node{ObjectMeta: metav1.ObjectMeta{Name: nodeName}} factory.schedulerCache.RemoveNode(&node) // invalidate cached predicate for the node if factory.enableEquivalenceClassCache { factory.equivalencePodCache.InvalidateAllCachedPredicateItemOfNode(nodeName) } } } </ins> } else { glog.Errorf("Error scheduling %v %v: %v; retrying", pod.Namespace, pod.Name, err) }
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In version 1.8.0, accessing the container stats via Kubelet API proxy using the path returns 503. What you expected to happen: In versions prior to 1.8.0, the container stats were returned. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.8.0 OS (e.g. from /etc/os-release): Mac OS X Install tools: Minikube
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
does the summary API also have issues? ?
The summary API works as expected. The affected endpoints are:
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
/remove-lifecycle stale
/remove-lifecycle rotten
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
Hmm... this fell of my radar a bit. If you go directly to the node, do you get a response?
no response either. I've created that fixes the issue. I think there has been a refactoring introduced in version 1.8 that broke the sequence of objects initialisation for that endpoint.

Discussion:
klet.containerRuntime = runtime klet.runner = runtime <ins> runtimeCache, err := kubecontainer.NewRuntimeCache(klet.containerRuntime) if err != nil { return nil, err } klet.runtimeCache = runtimeCache </ins> if cadvisor.UsingLegacyCadvisorStats(containerRuntime, remoteRuntimeEndpoint) { klet.StatsProvider = stats.NewCadvisorStatsProvider( klet.cadvisor,

experimentalCheckNodeCapabilitiesBeforeMount, keepTerminatedPodVolumes) <del> runtimeCache, err := kubecontainer.NewRuntimeCache(klet.containerRuntime) if err != nil { return nil, err } klet.runtimeCache = runtimeCache </del> klet.reasonCache = NewReasonCache() klet.workQueue = queue.NewBasicWorkQueue(klet.clock) klet.podWorkers = newPodWorkers(klet.syncPod, kubeDeps.Recorder, klet.workQueue, klet.resyncInterval, backOffPeriod, klet.podCache)
Change:
First, the formatting. Second, "init-ctr-demo_demos" is an internal artifact, not fit for human-facing errors. Third, the container DOES exist, it's just in a terminating state.
The formatting issue should be fixed by . Regarding to the pod name, I think is better. As for the pod name, the error message is from the HTTP response of kubelet server. I've looked at the code, functions defined in interface are using ($podName_podNamespace) to identify a pod. Without spiting the parameter into two separated parameters, it could be tricky to change the output format of an error message. Personally I would prefer to change the signatures, but I don't know if we are planing to do it. In order to improve the readability, I a client-side check for pod status. See .

Discussion:
} fn := func() error { <del> if !p.Quiet && stderr != nil { fmt.Fprintln(stderr, "If you don't see a command prompt, try pressing enter.") } </del> restClient, err := restclient.RESTClientFor(p.Config) if err != nil { return err

return p.Attach.Attach("POST", req.URL(), p.Config, p.In, p.Out, p.Err, t.Raw, sizeQueue) } <ins> if !p.Quiet && stderr != nil { fmt.Fprintln(stderr, "If you don't see a command prompt, try pressing enter.") } </ins> if err := t.Safe(fn); err != nil { return err }
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?: /assign What happened: Volume got bound to PV on node "kubernetes-minion-group-82c8" When the pod went back through scheduling, the predicate returned success for other nodes even though we should have updated the PV cache to point to the PVC: I think in , instead of continuing if the node affinity doesn't match, it should fail if the PV is prebound.
This causes two issues: On the second pass, the scheduler may choose a different node. Then in Assume/Bind volumes, we'll also prebind a second set of PVs. If the scheduler chose a different node on the second pass, and the PVCs became fully bound in between the predicates and assume volumes, then assume volumes will return success and the pod will get scheduled to the wrong node.

Discussion:
continue } <ins> nodeAffinityValid := true </ins> if node != nil { // Scheduler path, check that the PV NodeAffinity // is satisfied by the node err := volumeutil.CheckNodeAffinity(volume, node.Labels) if err != nil { <del> continue </del> <ins> nodeAffinityValid = false </ins> } }

if volumeQty.Cmp(requestedQty) < 0 { continue } <ins> // If PV node affinity is invalid, return no match. // This means the prebound PV (and therefore PVC) // is not suitable for this node. if !nodeAffinityValid { return nil, nil } </ins> return volume, nil }

// - volumes bound to another claim // - volumes whose labels don't match the claim's selector, if specified // - volumes in Class that is not requested <ins> // - volumes whose NodeAffinity does not match the node </ins> if volume.Spec.ClaimRef != nil { continue } else if selector != nil && !selector.Matches(labels.Set(volume.Labels)) {

if v1helper.GetPersistentVolumeClass(volume) != requestedClass { continue } <ins> if !nodeAffinityValid { continue } </ins> if node != nil { // Scheduler path

pvc.Spec.StorageClassName = &classWait pvc.Name = "claim02" }), <del> node: node2, </del> <ins> node: node3, </ins> }, "success-bad-and-good-node-affinity": { expectedMatch: "affinity-pv3",

failReasons := []algorithm.PredicateFailureReason{} if !boundSatisfied { <del> glog.V(5).Info("Bound PVs not satisfied for pod %v/%v, node %q", pod.Namespace, pod.Name, node.Name) </del> <ins> glog.V(5).Infof("Bound PVs not satisfied for pod %v/%v, node %q", pod.Namespace, pod.Name, node.Name) </ins> failReasons = append(failReasons, ErrVolumeNodeConflict) } if !unboundSatisfied { <del> glog.V(5).Info("Couldn't find matching PVs for pod %v/%v, node %q", pod.Namespace, pod.Name, node.Name) </del> <ins> glog.V(5).Infof("Couldn't find matching PVs for pod %v/%v, node %q", pod.Namespace, pod.Name, node.Name) </ins> failReasons = append(failReasons, ErrVolumeBindConflict) }

} // All volumes bound or matching PVs found for all unbound PVCs <del> glog.V(5).Info("All PVCs found matches for pod %v/%v, node %q", pod.Namespace, pod.Name, node.Name) </del> <ins> glog.V(5).Infof("All PVCs found matches for pod %v/%v, node %q", pod.Namespace, pod.Name, node.Name) </ins> return true, nil, nil }
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: param is not validated in func Validate What you expected to happen: validate admission plugins, if not registered, return err to prevent going on until call . 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 auth
/kind bug
from the user's perspective, a reasonable error is returned

Discussion:
if errs := options.Audit.Validate(); len(errs) > 0 { errors = append(errors, errs...) } <ins> if errs := options.Admission.Validate(); len(errs) > 0 { errors = append(errors, errs...) } </ins> if errs := options.InsecureServing.Validate("insecure-port"); len(errs) > 0 { errors = append(errors, errs...) }

"github.com/spf13/pflag" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/apiserver/pkg/admission" "k8s.io/apiserver/pkg/admission/initializer" admissionmetrics "k8s.io/apiserver/pkg/admission/metrics"

} func (a *AdmissionOptions) Validate() []error { <ins> if a == nil { return nil } </ins> errs := []error{} <ins> registeredPlugins := sets.NewString(a.Plugins.Registered()...) for _, name := range a.PluginNames { if !registeredPlugins.Has(name) { errs = append(errs, fmt.Errorf("admission-control plugin %q is invalid", name)) } } </ins> return errs }