jiebi/CodeConvo huggingface dataset:
Change:
// changes to Spec are not allowed, but updates to label/and some annotations are OK. // no-op updates pass validation. if !apiequality.Semantic.DeepEqual(newPvcClone.Spec, oldPvcClone.Spec) { <del> specDiff := diff.ObjectDiff(newPvcClone.Spec, oldPvcClone.Spec) </del> <ins> specDiff := cmp.Diff(oldPvcClone.Spec, newPvcClone.Spec) </ins> allErrs = append(allErrs, field.Forbidden(field.NewPath("spec"), fmt.Sprintf("field is immutable after creationn%v", specDiff))) } }

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 --pod with nodeSeletor edit pod, delete the nodeSeletor field report error with: ! The errors message should displayed as: Because the nodeSeletor is been deleted with this edit. 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:
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 api
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig api 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 api-machinery
/remove-sig api-machinery /sig apps
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]:
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]:
/remove-lifecycle stale
/remove-lifecycle rotten
Change:
name: csi-data-dir - name: hostpath <del> image: quay.io/k8scsi/hostpathplugin:v1.4.0-rc1 </del> <ins> image: quay.io/k8scsi/hostpathplugin:v1.4.0-rc2 </ins> args: - "--drivername=hostpath.csi.k8s.io" - "--v=5"

Discussion:
What happened: https://k8s- These tests failed consistently: Anything else we need to know?: Volume snapshot tests need to be reworked to use / helper functions that support block volume mode. In addition, csi-driver-host-path fails when restoring block volume snapshots. /assign /sig storage
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: https://k8s- Anything else we need to know?: Volume snapshot tests need to be reworked to use / helper functions that support block volume mode. In addition, csi-driver-host-path fails when restoring block volume snapshots. /sig stroage 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
hostpath driver fix:
E2e test fix: (needs hostpath driver release first).
Change:
<ins> // +build windows /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package metrics import ( "golang.org/x/sys/windows" ) func getProcessStart() (float64, error) { processHandle := windows.CurrentProcess() var creationTime, exitTime, kernelTime, userTime windows.Filetime if err := windows.GetProcessTimes(processHandle, &creationTime, &exitTime, &kernelTime, &userTime); err != nil { return 0, err } return float64(creationTime.Nanoseconds() / 1e9), nil } </ins>

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: Start kubelet on a Windows node and you will get this error: What you expected to happen: The process start time to be read appropriately for Windows How to reproduce it (as minimally and precisely as possible): Start kubelet on a Windows node Anything else we need to know?: The gauge falls back to but we get this error. This information is avaliable via the windows package so we should be able to get an accurate time. Environment: Kubernetes version (use ): 1.20.1 Cloud provider or hardware configuration: azure OS (e.g: ): Windows 2019 Kernel (e.g. ): Version 10.0..1637 Install tools: aks-engine (but would be any) Network plugin and version (if this is a network-related bug): Others: /sig windows /assign
/triage accepted
Change:
import ( "errors" "fmt" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> ) // MessageCountMap contains occurrence for each error message.

Discussion:
What happened: I configured my API server with a Webhook token authentication server by way of the "authentication-token-webhook-config-file" command-line flag, and confirmed that the API server does pass bearer tokens through, issuing HTTP POST requests with a JSON-encoded body. When my Webhook server indicates authentication failure, it responds with HTTP status code 200 and a JSON-encoded in the body, this time with the object's "Error" field populated. Here's an example: When the API server receives this response, it refuses the original motivating request with an HTTP status code 401 response, but the API server writes the following into its log file: This use of this default error message is due to an omission in file , where , and . What you expected to happen: The API server should instead log a message that includes the value from . Per a brief discussion with , he agreed that the API server log message should include such an error message from the Webhook server, provided it's present and nonempty. How to reproduce it (as minimally and precisely as possible): Configure an API server to delegate to a Webhook token authentication server. Force that Webhook server to respond "successfully" with an HTTP 200 response, but with the "Authenticated" field set to false (or omitted) and with a particular error message in the "Error" field. Make an HTTP request of the API server with an HTTP "Authentication" header with a value starting with the string "Bearer " followed by at least one more character. Inspect the logs from the API server, looking for a message that begins with "Unable to authenticate the request due to an error." Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS EC2 OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: kubeadm_
/sig auth
/assign
Change:
{% endif -%} {% set params = "--master=127.0.0.1:8080" + " " + cluster_name + " " + cluster_cidr + " " + allocate_node_cidrs + " " + service_cluster_ip_range + " " + terminated_pod_gc + " " + enable_garbage_collector + " " + cloud_provider  + " " + cloud_config + " " + service_account_key + " " + log_level + " " + root_ca_file -%} <del> {% set params = params + " " feature_gates %} </del> <ins> {% set params = params + " " + feature_gates -%} </ins> # test_args has to be kept at the end, so they'll overwrite any prior configuration

Discussion:
Starting the vargant setup with results in the following error: - is missing after And the Cluster is stuck at the validation step (doesn't come up).
Change:
id: monitoring-influxdb port: 80 containerPort: 8086 <ins> labels: name: influxdb kubernetes.io/cluster-service: "true" </ins> selector: name: influxGrafana

Discussion:
As per we should add a common label to all of our add-on pods: DNS, logging, monitoring, etc. The proposal is to add "": "true" for now.
FWIW "true" has to be quoted in YAML
Can you close this one once it's completed.
Change:
ovs-vsctl set Bridge ${OVS_SWITCH} stp_enable=true # modify the docker service file such that it uses the kube docker bridge and not its own <del> sed -ie "s/ExecStart=/usr/bin/docker -d/ExecStart=/usr/bin/docker -d -b=${DOCKER_BRIDGE} --iptables=false/g" /usr/lib/systemd/system/docker.service </del> <ins> sed -ie "s/ExecStart=/usr/bin/docker -d/ExecStart=/usr/bin/docker -d -b=${DOCKER_BRIDGE} --iptables=false --ip-masq=false/g" /usr/lib/systemd/system/docker.service </ins> systemctl daemon-reload systemctl restart docker.service

Discussion:
We need to version-lock to docker 1.2 until they fix this flag, or else we need to drop 1.2 support, or else we need to detect the docker version before writing the flags file. - we need something here ASAP.
After a little bit thinking, I think we shouldn't have the problem. kube-push only updates our own binaries, not docker's. kube-up builds a new cluster which will pull the latest docker, but we can change docker's defaults, so that at the minion's provision stage, we disable both --iptables and --ip-masq.
Something like for gce.
Change:
*completedConfig } <ins> // AddHealthChecks adds a health check to our config to be exposed by the health endpoints // of our configured apiserver. We should prefer this to adding healthChecks directly to // the config unless we explicitly want to add a healthcheck only to a specific health endpoint. func (c *Config) AddHealthChecks(healthChecks ...healthz.HealthChecker) { for _, check := range healthChecks { c.HealthzChecks = append(c.HealthzChecks, check) c.LivezChecks = append(c.LivezChecks, check) c.ReadyzChecks = append(c.ReadyzChecks, check) } } </ins> // Complete fills in any fields not set that are required to have valid data and can be derived // from other fields. If you're going to `ApplyOptions`, do that first. It's mutating the receiver. func (c *Config) Complete(informers informers.SharedInformerFactory) CompletedConfig {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: The and urls do not provide as much information about the cluster as much as does. It's expected to see and (if kms is enabled) but does not. What you expected to happen: and url to include and How to reproduce it (as minimally and precisely as possible): any 1.16 pre-release cluster the server url for , and Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: IBM OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others: Logs: healthz readyz livez /sig api-machinery
/sig api-machinery
/assign
Change:
The former selects all resources with key equal to `environment` and value equal to `production`. The latter selects all resources with key equal to `tier` and value distinct from `frontend`. <del> One could filter for resources in `production` but not `frontend` using the comma operator: `environment=production,tier!=frontend` </del> <ins> One could filter for resources in `production` excluding `frontend` using the comma operator: `environment=production,tier!=frontend` </ins> ### _Set-based_ requirement <del> _Set-based_ label requirements allow filtering keys according to a set of values. Matching objects must have all of the specified labels (i.e. all keys and at least one of the values specified for each key). Three kind of operators are supported: `in`,`notin` and exists (only the key identifier). For example: </del> <ins> _Set-based_ label requirements allow filtering keys according to a set of values. Matching objects must have all of the specified labels (i.e. all keys and at least one of the values specified for each key). Three kinds of operators are supported: `in`,`notin` and exists (only the key identifier). For example: </ins> ``` environment in (production, qa)

Discussion:
The suggests we support both "equality-based" and "set-based" label selectors, but actually we only support "==" selector right now. This is confusing. People are asking questions on IRC. We should update the doc in both github and
cc
We support the set-based selectors for filtering GET/watch requests. We support equality-based selectors, represented as maps, for API resources, such as ReplicationController, Service, and Pod nodeSelector.
Even if it's technically correct people are getting confused, so we need to fix the documentation.
Ref
sorry I see this only now. I'm ok to better explain the difference between set-based and equality based but I would need of some example of questions on IRC. May you have some of them? Otherwise we may clearly write that kubectl <command-l <selectorsupports set-based and equality based selector while API resources supports only equality-based.
I was thinking of making the difference between selectors in kubectl and in API clear.
cool, I can work on this if you've not already started.
By all means - please do:)
:)
Change:
"reflect" "k8s.io/klog/v2" <del> "k8s.io/kubernetes/pkg/scheduler/profile" </del> v1 "k8s.io/api/core/v1" storagev1 "k8s.io/api/storage/v1"

Discussion:
What happened: An extra scheduling attempt is observed in some scenarios when kube-scheduler already has already assumed a pod and this has entered the binding routine. If, during this time, a pod update is received, the pod is back to the scheduling queue, even if binding succeeds. This is the correct behavior, as scheduling conditions might change. However this updates could just be unrelated status updates, such as updates to pod conditions. We observe an extra scheduling attempt, which is visible in the log line: Which indicates that an attempt was made when the pod was already scheduled. What you expected to happen: No extra scheduling attempts How to reproduce it (as minimally and precisely as possible): This depends on other controllers running on the cluster that might report pod conditions. One such controller is
/sig scheduling
Change:
return nil }, time.Minute, 5*time.Second).Should(gomega.BeNil()) <del> // Wait for cAdvisor to collect 2 stats points </del> <ins> ginkgo.By("Waiting 15 seconds for cAdvisor to collect 2 stats points") </ins> time.Sleep(15 * time.Second) // Setup expectations.

Discussion:
Which jobs are failing: ci-cri-containerd-node-e2e Which test(s) are failing: Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api Since when has it been failing: 2020 10-12 09:04 PDT Since Testgrid link: Reason for failure: Capability set incorrectly. CAPNETRAW should be NETRAW. I1013 18:39:19.058] Oct 13 18:10:51.403: INFO: At 2020-10-13 18:09:34 +0000 UTC - event for stats-busybox-0: {kubelet tmp-node-e2e--cos-81--1210-0} Failed: Error: failed to create containerd task: OCI runtime create failed: starting container process caused: unknown capability "CAPCAPNET_RAW": unknown Anything else we need to know: I have no idea where this is documented. It's a best guess.
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
it's a node_e2e test so /sig node
Seems like there's some dispute on who is doing the correct thing.
I would like to have a try.
please see discussion in
Change:
allErrs = append(allErrs, ValidateVolumeDevices(ctr.VolumeDevices, volMounts, volumes, path.Child("volumeDevices"))...) allErrs = append(allErrs, validatePullPolicy(ctr.ImagePullPolicy, path.Child("imagePullPolicy"))...) allErrs = append(allErrs, ValidateResourceRequirements(&ctr.Resources, podClaimNames, path.Child("resources"), opts)...) <ins> allErrs = append(allErrs, validateResizePolicy(ctr.ResizePolicy, path.Child("resizePolicy"))...) </ins> allErrs = append(allErrs, ValidateSecurityContext(ctr.SecurityContext, path.Child("securityContext"))...) return allErrs }

Discussion:
The newly field field is not being validated. field should be validated. We can create a pod with invalid to reproduce this. 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
/assign /sig node /priority important-soon /milestone v1.27 adding to 1.27 milestone to resolve if possible
I'll try this for v1.27 if you don't mind.
getting a PR open, reviewed, and green is always good. we'll evaluate it for risk and if there's a second release candidate we can likely include it
Nice catch! Please review fix: This likely got dropped either during port-over of the or during bad rebase. I should not have left the . Gotta run to get my kid prepped, dr. appt and then school drop. So I'll try and add an E2E test for this later today. please hold for e2e test (but we should fix this in 1.27)
I realized you were working on a fix as well only after I sent my fix out and was catching up on emails at doc office (rushed morning). I didn't mean to step over your effort to fix it, sorry about that.
I am completely fine with that. Thanks for the fix :)
Change:
k8s.io/sample-apiserver/pkg/registry k8s.io/sample-apiserver/pkg/registry/wardle/fischer k8s.io/sample-apiserver/pkg/registry/wardle/flunder <del> # k8s.io/system-validators v1.5.0 => k8s.io/system-validators v1.5.0 </del> <ins> # k8s.io/system-validators v1.6.0 => k8s.io/system-validators v1.6.0 </ins> ## explicit k8s.io/system-validators/validators # k8s.io/utils v0.0.0-20210930125809-cb0fa318a74b => k8s.io/utils v0.0.0-20210930125809-cb0fa318a74b

Discussion:
every k8s release, if changes are to we release a new version of the library and vendor it in this repository. TODO: [ ] wait for changes to accumulate in [ ] add new release in before the k8s 1.23 release [ ] vendor the new release in k/k (example PR: )
/sig cluster-lifecycle node /milestone v1.23 /assign
/triage accepted
/cc
Change:
switch mode { case kubeproxyconfig.ProxyModeIPTables: <ins> iptablesCTStateInvalidDroppedMetricCollector := newNFAcctMetricCollector(IPTablesCTStateInvalidDroppedNFAcctCounter, iptablesCTStateInvalidDroppedPacketsDescription) </ins> if iptablesCTStateInvalidDroppedMetricCollector != nil { legacyregistry.CustomMustRegister(iptablesCTStateInvalidDroppedMetricCollector) } <ins> localhostNodePortsAcceptedMetricsCollector := newNFAcctMetricCollector(LocalhostNodePortAcceptedNFAcctCounter, localhostNodePortsAcceptedPacketsDescription) </ins> if localhostNodePortsAcceptedMetricsCollector != nil { legacyregistry.CustomMustRegister(localhostNodePortsAcceptedMetricsCollector) }

Discussion:
The module now logs two errors during module initialization. Simply loading the module will cause two errors to be printed to stderr if the code is not run as root, or is run on a node without nfacct support. This is due to being used when creating Prometheus metrics during module variable initialization, which calls if the nfacct client cannot be initialized. This regression was introduced by: K3s ships all the various Kubernetes components bundled in a single multicall binary, which means that our now logs these errors when it is run as a non-root user. No error logs on module init cc <details</detailsn/a n/a n/a n/a n/a area/proxy sig/network
/sig network
/triage accepted /assign
I was about to fix this, this initialization happens in the unit tests as well .
thanks for the quick response! Do you think you'll have a patch that we could use temporarily for k3s until v1.31.1 is out? We were considering just removing the call for our initial 1.31 release, unless you have a better suggestion.
can you confirm is fine?
Change:
- deleteCoreV1Node - deleteStorageV1CollectionCSINode - deleteStorageV1CSINode <del> - getInternalApiserverAPIGroup - getResourceAPIGroup - getStoragemigrationAPIGroup </del> - listStorageV1CSINode - patchStorageV1CSINode - patchStorageV1VolumeAttachmentStatus

Discussion:
The following api endpoints are currently in - As each group has no stable endpoints they are reported in as promoted to stable without tests. The current logic for endpoints will address this issue.
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 architecture /area test