jiebi/CodeConvo huggingface dataset:
Change:
# Optional: [Experiment Only] Run kube-proxy as a DaemonSet if set to true, run as static pods otherwise. KUBE_PROXY_DAEMONSET="${KUBE_PROXY_DAEMONSET:-false}" # true, false <ins> # Optional: duration of cluster signed certificates. CLUSTER_SIGNING_DURATION="${CLUSTER_SIGNING_DURATION:-}" </ins> # Optional: enable pod priority ENABLE_POD_PRIORITY="${ENABLE_POD_PRIORITY:-}" if [[ "${ENABLE_POD_PRIORITY}" == "true" ]]; then

Discussion:
/kind e2e-test-failure GCE serial and GCI GCE serial started failing last evening https://k8s- https://k8s-
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/testing: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
https://k8s- is still green, I would suspect something ~last Friday afternoon gets merged
Here is what I found, after a while, the node lost their authorization to connect to API server. I believe this has the same root cause as
I am going to revert offending pr () to see if it helps. EDIT: Looks like is in the process of reverting it:

ref Test is failing on GCE slow and GCI GCE slow: https://k8s- https://k8s- Example failure https://k8s-
The test nodes appear to lose their authorization for accessing resources about 26m into the test. One of many "Unauthorized" errors starting at
, does this ring any bells ?
The certificates are all expiring:
I believe this is the regression introduced cc/ Can you guys take a look?
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. kind: Must specify exactly one of [, , ]. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
thanks. I'll open a PR to revert that.
Revert here
Change:
framework.ImagePrePullList = NodePrePullImageList.Union(commontest.PrePulledImages) // Images from extra envs framework.ImagePrePullList.Insert(getNodeProblemDetectorImage()) <del> framework.ImagePrePullList.Insert(getSRIOVDevicePluginImage()) </del> <ins> if sriovDevicePluginImage, err := getSRIOVDevicePluginImage(); err != nil { klog.Errorln(err) } else { framework.ImagePrePullList.Insert(sriovDevicePluginImage) } if gpuDevicePluginImage, err := getGPUDevicePluginImage(); err != nil { klog.Errorln(err) } else { framework.ImagePrePullList.Insert(gpuDevicePluginImage) } </ins> } func getNodeProblemDetectorImage() string {

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: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig testing
/sig node /triage accepted
Change:
if res.StatusCode >= http.StatusOK && res.StatusCode < http.StatusBadRequest { if res.StatusCode >= http.StatusMultipleChoices { // Redirect klog.V(4).Infof("Probe terminated redirects for %s, Response: %v", url.String(), *res) <del> return probe.Warning, body, nil </del> <ins> return probe.Warning, fmt.Sprintf("Probe terminated redirects, Response body: %v", body), nil </ins> } klog.V(4).Infof("Probe succeeded for %s, Response: %v", url.String(), *res) return probe.Success, body, nil

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 --Used a HTTP probe with external redirect: Got warning: Kubelet logs show: Warning messages either show additional context or don't show . I would probably have expected or just Not a big deal, just a bit confusing message Apply yaml above Kubernetes version (use ): v1.22.0-beta.1 Cloud provider or hardware configuration: kind OS (e.g: ): linux Kernel (e.g. ): 5.10.40 Install tools: kind /sig node
According to See and
thanks! I am not concerned about the actual implementation behavior, but rather the event: . We should not have an event ending with as it denotes there is more information to follow, but there is not.
Got it. /assign
/triage accepted I send to fix this issue.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
In 1.18 (because of EKS long term support I don't really want to get into), I get this: This is mildly aggravating, as it means I get fourteen lines of warning logs indicating that a service which exists solely to provide redirects is working as expected. Does this bug mean that I'll instead get an even more aggravating warning when I eventually upgrade? :) I found this bug while looking for a way to tell the probe that "getting a 308 or 302 or <insert one or a list of values heremeans success". It'd be ideal in my mind if the httpget probe allowed an "ok return values array" which accepted either single values or ranges, perhaps with a default value like .

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
Change:
"k8s.io/kubernetes/pkg/fields" "k8s.io/kubernetes/pkg/labels" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/util/errors" </ins> "k8s.io/kubernetes/pkg/watch" )

Discussion:
When a resource violates the limitrange, both for cpu and memory, only one error will be returned at a time. That means when a user is creating such a resource, first it will fail and return something like , them user may edit the cpu usage and create again, then fail again and get . It seem admission controls want to reject the request as fast as possible, if error occurs. But in this case, it may give users a bad experience. Would it be better to aggregate all errors and return them at one time. Also, the error message may cause misunderstanding. , it means the resource requested is 3, it may also cause a confusion that it is limited to 3.
Closing since it's fixed
Change:
{ testName: "RunAsUserName's User is too long", windowsOptions: &core.WindowsSecurityContextOptions{ <del> RunAsUserName: toPtr(strings.Repeat("a", maxRunAsUserNameUserLength)), </del> <ins> RunAsUserName: toPtr(strings.Repeat("a", maxRunAsUserNameUserLength+1)), </ins> }, <del> expectedErrorSubstring: "runAsUserName's User length must be under", </del> <ins> expectedErrorSubstring: "runAsUserName's User length must not be longer than", </ins> }, { testName: "RunAsUserName's User cannot contain only spaces or periods",

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: Currently, the character limit for the usernames set in the field is 20, which is too low, considering that "ContainerAdministrator" is a valid username and it is longer than 20 characters. A user should be able to run containers as Administrator, if needed. What you expected to happen: Users should be able to spawn pods which run as. How to reproduce it (as minimally and precisely as possible): WindowsRunAsUserName feature gate. () Anything else we need to know?: /sig windows /priority important-soon /milestone 1.16 Environment: Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: N/A OS (e.g: ): Windows Server 2019 Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others:
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : <!-- 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! --2. ` /priority important-soon /milestone 1.16 Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: N/A OS (e.g: ): Windows Server 2019 Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: </details
/milestone v1.16
Change:
} } <del> fakeSource.accessToken = "fake token 2" </del> <ins> fakeSource.token = newFakeAzureToken("fake token 2", time.Now().Add(3600*time.Second)) </ins> token, err = tokenSource.Token() if err != nil { t.Errorf("failed to retrieve the cached token: %v", err)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, when AAD login is configured, refresh token timeout would make kubectl print an error, not able to re-login without manually remove the tokens. Expect kubectl to promote user to login again. Why is this needed: Configure refresh-token timeout from Azure is a way to force re-login after inactivity. kubectl doesn't promote re-login makes users harder to apply timeout policy.
/sig azure
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig azure 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
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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
/area provider/azure
the root cause of this issue is in this first gets the cached token (result of device code flow) at it's trying to refresh an expired token at and failed. An error is returned. Since the expired token is still in the cache, it will always hit this path until user removes the token from kubeconfig. the fix should be: the token from cache a retry to re-initiate the device code flow in
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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
/sig cli These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
I'm working on it.
are you working on it? I will grab it if I dont hear it from you :)
have the code ready will try PR this weekend Best, Ping
/assign
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
Closing as merged
Change:
// Do the actual prebinding. Let the PV controller take care of the rest // There is no API rollback if the actual binding fails for _, binding = range bindings { <del> klog.V(5).InfoS("bindAPIUpdate: binding PV to PVC", "pod", klog.KObj(pod), "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc)) </del> // TODO: does it hurt if we make an api call and nothing needs to be updated? <del> klog.V(2).InfoS("Claim bound to volume", "PVC", klog.KObj(binding.pvc), "PV", klog.KObj(binding.pv)) </del> <ins> klog.V(5).InfoS("Updating PersistentVolume: binding to claim", "pod", klog.KObj(pod), "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc)) </ins> newPV, err := b.kubeClient.CoreV1().PersistentVolumes().Update(ctx, binding.pv, metav1.UpdateOptions{}) if err != nil { <del> klog.V(4).InfoS("Updating PersistentVolume: binding to claim failed", "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc), "err", err) </del> <ins> klog.V(4).InfoS("Updating PersistentVolume: binding to claim failed", "pod", klog.KObj(pod), "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc), "err", err) </ins> return err } <del> klog.V(4).InfoS("Updating PersistentVolume: bound to claim", "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc)) </del> <ins> klog.V(2).InfoS("Updated PersistentVolume with claim. Waiting for binding to complete", "pod", klog.KObj(pod), "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc)) </ins> // Save updated object from apiserver for later checking. binding.pv = newPV lastProcessedBinding++

Discussion:
This line reads as if the bound has already happened: But, if I read correctly, the bound happens immediately after: And there is even a wait for confirmation after: The log line to better describe the actual state and another log line at V(2) to confirm that the operation ended. No response all supported versions <details</details<details</details<details</details<details</details<details</details
/sig storage
cc
/triage accepted
Change:
const discoveryPath = "/apis" func init() { <del> // Register conversion for apidiscovery apidiscoveryv2.SchemeBuilder.Register(apidiscoveryv2conversion.RegisterConversions) </del> utilruntime.Must(apidiscoveryv2.AddToScheme(scheme)) utilruntime.Must(apidiscoveryv2beta1.AddToScheme(scheme)) <ins> // Register conversion for apidiscovery utilruntime.Must(apidiscoveryv2conversion.RegisterConversions(scheme)) </ins> codecs = runtimeserializer.NewCodecFactory(scheme) }

Discussion:
Seeing data race flakes in unit tests: Appears to have just been in /sig api-machinery /priority critical-urgent /assign /cc
This code is mutating the package-level schemebuilder: I think it should be adding the conversions to the local scheme instead:
Fixed in (found several instances)
/triage accepted
Change:
func TestMasterProcessMetrics(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> metrics, err := scrapeMetrics(s) if err != nil {

Discussion:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.
Change:
} lbName := *lb.Name klog.V(2).Infof("reconcileLoadBalancer for service(%s): lb(%s) wantLb(%t) resolved load balancer name", serviceName, lbName, wantLb) <del> lbFrontendIPConfigName := az.getFrontendIPConfigName(service, subnet(service)) </del> <ins> lbFrontendIPConfigName := az.getFrontendIPConfigName(service) </ins> lbFrontendIPConfigID := az.getFrontendIPConfigID(lbName, lbFrontendIPConfigName) lbBackendPoolName := getBackendPoolName(az.ipv6DualStackEnabled, clusterName, service) lbBackendPoolID := az.getBackendPoolID(lbName, lbBackendPoolName)

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 the specified internal LB uses a subnet with longer name, the LB configuration will fail with following error: What you expected to happen: When constructing the frontend IP configuration name and the load balancing rules name, the subnet name should be truncated if too long. How to reproduce it (as minimally and precisely as possible): Use a subnet that has long name (70 charactors) and create ILB service. Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: azure OS (e.g: ): Ubuntu 16.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure /assign
Change:
if len(zonesToSearch) == 0 { // If zone is not provided, get the shared datastore across all node VMs. klog.V(4).Infof("Validating if datastore %s is shared across all node VMs", datastoreName) <del> sharedDsList, err = getSharedDatastoresInK8SCluster(ctx, vs.nodeManager) </del> <ins> sharedDSFinder := &sharedDatastore{ nodeManager:         vs.nodeManager, candidateDatastores: candidateDatastoreInfos, } datastoreInfo, err = sharedDSFinder.getSharedDatastore(ctx) </ins> if err != nil { klog.Errorf("Failed to get shared datastore: %+v", err) return "", err } <del> // Prepare error msg to be used later, if required. err = fmt.Errorf("The specified datastore %s is not a shared datastore across node VMs", datastoreName) </del> <ins> if datastoreInfo == nil { err = fmt.Errorf("The specified datastore %s is not a shared datastore across node VMs", datastoreName) klog.Error(err) return "", err } </ins> } else { // If zone is provided, get the shared datastores in that zone. klog.V(4).Infof("Validating if datastore %s is in zone %s ", datastoreName, zonesToSearch)

Discussion:
Currently whenever a vSphere volume is provisioned, we are looking at all nodes in the cluster and then fetching their hosts and then their datastores and then ensuring that selected datastore in present on all the nodes. This is done every time a new PVC is provisioned. It can be pretty expensive in large clusters and number of involved API calls can be big. /sig storage /area vsphere cc
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Currently whenever a vSphere volume is provisioned, we are looking at all nodes in the cluster and then fetching their hosts and then their datastores and then ensuring that selected datastore in present on all the nodes. This is done every time a new PVC is provisioned. /area vsphere 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
/triage accepted
/assign
Change:
visibility = ["//visibility:public"], deps = [ "//pkg/scheduler/algorithm/predicates:go_default_library", <del> "//pkg/scheduler/framework/plugins/migration:go_default_library", </del> "//pkg/scheduler/framework/v1alpha1:go_default_library", "//pkg/scheduler/nodeinfo:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library",

Discussion:
/sig scheduling /priority important-soon See as an example. Part of /assign
GitHub didn't allow me to assign the following users: angao. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /sig scheduling /priority important-soon 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
thx, I will do it soon.
Change:
}, []string{NodeLabelKey}, ) <del> // ContainersPerPodCount is a Counter that tracks the number of containers per pod. </del> <ins> // ContainersPerPodCount is a Histogram that tracks the number of containers per pod. </ins> ContainersPerPodCount = metrics.NewHistogram( &metrics.HistogramOpts{ Subsystem:      KubeletSubsystem, Name:           "containers_per_pod_count", Help:           "The number of containers per pod.", <del> Buckets:        metrics.DefBuckets, </del> <ins> Buckets:        metrics.ExponentialBuckets(1, 2, 5), </ins> StabilityLevel: metrics.ALPHA, }, )

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: There is an metric in kubelet, which is used to track the number of containers per pod. The current metric data format is The number of containers in the pod will definitely not be less than 1, so the bucket is set to have optimized space What you expected to happen: Would it be better if optimized to the following bucket How to reproduce it (as minimally and precisely as possible): curl kubelet metrics endpoint Anything else we need to know?: Environment: Kubernetes version (use ): 1.19,1.20 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: /sig node /area kubelet
/assign
/triage accepted
Change:
if !isHardEvictionThreshold(thresholdToReclaim) { gracePeriodOverride = m.config.MaxPodGracePeriodSeconds } <del> message, annotations := evictionMessage(resourceToReclaim, pod, statsFunc) </del> <ins> message, annotations := evictionMessage(resourceToReclaim, pod, statsFunc, thresholds, observations) </ins> var condition *v1.PodCondition if utilfeature.DefaultFeatureGate.Enabled(features.PodDisruptionConditions) { condition = &v1.PodCondition{

Discussion:
when the pod is evicted due to low imagefs.available, the prompt is difficult to understand. it showed: But the container was evicted not by exceeding its request of 0 ephemeral-storage, but due to reaching the evictionHard of the node. The correct prompt message points out the reason for the pod eviction. don't print "which exceeds its request of 0.", because the container was evicted not by exceeding its request of 0. % oc label mcp worker custom-kubelet-eviction=small-pods evictionHard by creating a kubeletconfig % oc create -f custom-kubelet- custom-kubelet- several minutes, the mcp worker finish rolling out to the latest mc a pod % oc create -f hello-pod- hello-pod- a large file in container, make imagefs.available < 90Gi (the current available disk size is 111G ) command terminated with exit code 137 the node status the pod status % oc get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-pod-2 0/1 ContainerStatusUnknown 1 7m58s 10.131.0.7 ip-10-0-213- <none<none% oc get pod hello-pod-2 -o yaml No response <details</details<detailsaws </details<details</details<details</details<details</details<details</details
/sig node
/assign
/assign
/triage accepted