jiebi/CodeConvo huggingface dataset:
Change:
podNamespace:          pod.Namespace, podServiceAccountName: pod.Spec.ServiceAccountName, volName:               spec.Name(), <ins> MetricsProvider:       metricsProvider, </ins> }, runner:   runner, spec:     spec,

Discussion:
kind feature What happened: Currently there is no mechanism to report metrics as the flex plugins are not enabled to collect metrics. All flex volumes lack this feature as compared to in-tree/built-in drivers even though it is possible to collect such metrics for most of the plugins. What you expected to happen: Depending on the availability of the metrics from the mounted FS, flex plugins should allow to report metrics for the FS. How to reproduce it (as minimally and precisely as possible): The default behavior that can be proved easily by just running a command similar to the following command on a node that is running a flex volume. This will show that there are no metrics collected for flex volumes. kubectl proxy $curl 127.0.0.1:8001/api/v1/nodes/<IP/proxy/stats/summary Environment**: Kubernetes version (use ): 1.12 Cloud provider or hardware configuration: local x86 OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux KubeStorage 4.4.0-130-generic -Ubuntu SMP Thu Jun 14 08:53:28 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: Others: /sig storage
+1 Yes, it will be good, if flex volume can support atleast the default metrics( i.e ), which most of the volume plugins support now. Based upon flex plugin "capabilities" parameters, it can be decided, whether the plugin supports "default metrics" or "nil metrics".
Change:
</div> <div id="footer"> <div id="footer-text"> <del> Last updated 2016-11-08 08:09:17 UTC </del> <ins> Last updated 2016-11-18 14:07:18 UTC </ins> </div> </div> </body>

Discussion:
API documentation says is rounded up, but it is actually rounded down: The code shows it is rounded down, not up: and
Yes, the documentation is obsolete. We changed maxUnavailable to round down so that we wouldn't accidentally infer 100% unavailability for non-100 percentages. For example, maxSurge=25% and maxUanavailable=25% with a Deployment of 1 replica meant that we could scale down 1 before thus leading in 100% maxUnavailable (implicit).
Change:
errors = append(errors, fmt.Errorf("--max-resource-write-bytes can not be negative value")) } <ins> if err := validateHSTSDirectives(s.HSTSDirectives); err != nil { errors = append(errors, err) } </ins> return errors } <ins> func validateHSTSDirectives(hstsDirectives []string) error { // HSTS Headers format: Strict-Transport-Security:max-age=expireTime [;includeSubDomains] [;preload] // See https://tools.ietf.org/html/rfc6797#section-6.1 for more information allErrors := []error{} for _, hstsDirective := range hstsDirectives { if len(strings.TrimSpace(hstsDirective)) == 0 { allErrors = append(allErrors, fmt.Errorf("empty value in strict-transport-security-directives")) continue } if hstsDirective != "includeSubDomains" && hstsDirective != "preload" { maxAgeDirective := strings.Split(hstsDirective, "=") if len(maxAgeDirective) != 2 || maxAgeDirective[0] != "max-age" { allErrors = append(allErrors, fmt.Errorf("--strict-transport-security-directives invalid, allowed values: max-age=expireTime, includeSubDomains, preload. see https://tools.ietf.org/html/rfc6797#section-6.1 for more information")) } } } return errors.NewAggregate(allErrors) } </ins> // AddUniversalFlags adds flags for a specific APIServer to the specified FlagSet func (s *ServerRunOptions) AddUniversalFlags(fs *pflag.FlagSet) { // Note: the weird ""+ in below lines seems to be the only way to get gofmt to

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add the "Strict-Transport-Security" header to the API server responses. Why is this needed: Nessus scanner treats this as a Medium Risk in kubernetes 1.18.10.
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-machinery
/remove-sig api-machinery /sig auth
Change:
return volumes[0], nil } <ins> // applyUnSchedulableTaint applies a unschedulable taint to a node after verifying // if node has become unusable because of volumes getting stuck in attaching state. func (c *Cloud) applyUnSchedulableTaint(nodeName types.NodeName, reason string) { node, fetchErr := c.kubeClient.CoreV1().Nodes().Get(string(nodeName), metav1.GetOptions{}) if fetchErr != nil { glog.Errorf("Error fetching node %s with %v", nodeName, fetchErr) return } taint := &v1.Taint{ Key:    nodeWithImpairedVolumes, Value:  "true", Effect: v1.TaintEffectNoSchedule, } err := controller.AddOrUpdateTaintOnNode(c.kubeClient, string(nodeName), taint) if err != nil { glog.Errorf("Error applying taint to node %s with error %v", nodeName, err) return } c.eventRecorder.Eventf(node, v1.EventTypeWarning, volumeAttachmentStuck, reason) } </ins> // waitForAttachmentStatus polls until the attachment status is the expected value // On success, it returns the last attachment state. func (d *awsDisk) waitForAttachmentStatus(status string) (*ec2.VolumeAttachment, error) {

Discussion:
On AWS when we call "attach" of a volume then we periodically we check (via API call) if volume has indeed been attached. We run the check in a loop with timeout of 21 minutes. AWS documents that - if a volume is stuck in "attaching" state for too long, the node where volume is being attached is in "dirty" state and must be rebooted to fix the problem. Until node is rebooted, more pods with volumes to same node is only going be stuck in same state (i.e "attaching"). We propose that - if attach operation times out waiting for volume in "attaching" state, we should simply taint the node so as it can not affect other pods and a admin can manually fix the node. /sig aws /sig storage cc
Change:
--overrides="": An inline JSON override for the generated object. If this is non-empty, it is used to override the generated object. Requires that the object supply a valid apiVersion field. --port=-1: The port that this container exposes. -r, --replicas=1: Number of replicas to create for this container. Default is 1. <del> -t, --template="": Template string or path to template file to use when -o=template or -o=templatefile. </del> <ins> -t, --template="": Template string or path to template file to use when -o=template or -o=templatefile.  The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview] </ins> Global Flags: --alsologtostderr=false: log to standard error as well as files

Discussion:
periodic-conformance-main-k8s-main Kubernetes e2e suite.SynchronizedBeforeSuite 07/17 23:52PDT We saw a similar issue in , which was fixed by upgrading the control plane OS from Ubuntu 18.04 to 22.04. /sig cluster-lifecycle
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 /cc
/sig node It seems to be related to SWAP.
There is a bug in containerd that is fixed in v1.6.14. The test here is using v1.6.8. Kubernetes v1.27 supported containerd versions: 1.7.0+, 1.6.15+
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Still failing after is merged. Have we tried bumping the control plane OS image to ubuntu 22.04, like ?
Nevermind, the latest testgrid job might have been triggered before the PR was merged. I am observing this and will close this once I see the job passes.
Containerd version is already v1.6.21 in 's log There maybe still other problems.
can fix a similar failure in .
/close The failure of the swap is fixed by . The current failure is a flake that is mentioned in
Closing this issue. <detailsIn response to : /close The current failure is a flake that is mentioned in Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
) type NodeAddress struct { <del> Type    NodeAddressType `json:"type"` Address string          `json:"address"` </del> <ins> Type    NodeAddressType `json:"type" description:"node address type, one of Hostname, ExternalIP or InternalIP"` Address string          `json:"address" description:"the node address"` </ins> } // ResourceName is the name identifying various resources in a ResourceList.

Discussion:
PR had a few errors in its API objects, where the "description" field errors in its JSON declarations were missing. But, the "verify-" presubmit check didn't flag them. This should be investigated and fixed.
Could you please take a look at this?
Change:
<ins> /* Copyright 2021 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 convert import ( "sort" "strings" "testing" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/client-go/kubernetes/scheme" "k8s.io/kubernetes/pkg/api/legacyscheme" ) func TestKnownVersions(t *testing.T) { legacytypes := legacyscheme.Scheme.AllKnownTypes() alreadyErroredGroups := map[string]bool{} var gvks []schema.GroupVersionKind for gvk := range scheme.Scheme.AllKnownTypes() { gvks = append(gvks, gvk) } sort.Slice(gvks, func(i, j int) bool { if isWatchEvent1, isWatchEvent2 := gvks[i].Kind == "WatchEvent", gvks[j].Kind == "WatchEvent"; isWatchEvent1 != isWatchEvent2 { return isWatchEvent2 } if isList1, isList2 := strings.HasSuffix(gvks[i].Kind, "List"), strings.HasSuffix(gvks[j].Kind, "List"); isList1 != isList2 { return isList2 } if isOptions1, isOptions2 := strings.HasSuffix(gvks[i].Kind, "Options"), strings.HasSuffix(gvks[j].Kind, "Options"); isOptions1 != isOptions2 { return isOptions2 } if isInternal1, isInternal2 := gvks[i].Group == runtime.APIVersionInternal, gvks[j].Group == runtime.APIVersionInternal; isInternal1 != isInternal2 { return isInternal2 } return gvks[i].String() < gvks[j].String() }) for _, gvk := range gvks { if alreadyErroredGroups[gvk.Group] { continue } if _, legacyregistered := legacytypes[gvk]; !legacyregistered { t.Errorf("%v is not registered in legacyscheme. Add group %q (all internal and external versions) to convert/import_known_versions.go", gvk, gvk.Group) alreadyErroredGroups[gvk.Group] = true } } } </ins>

Discussion:
What happened: Tried to convert a v1beta1 Ingress object to v1, and received the following error: What you expected to happen: The conversion to work. How to reproduce it (as minimally and precisely as possible): Then run: /sig cli /assign
Can i work on this issue?
/assign
/triage accepted
Change:
all: push # Set this to the *next* version to prevent accidentally overwriting the existing image. <del> TAG = 1.4 </del> <ins> TAG = 1.5 </ins> webserver: webserver.go CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -ldflags '-w' ./webserver.go

Discussion:
test panicked: (root)/Kubernetes%%20suite/Monitoringverifymonitoringpodsandallclusternodesareavailableoninfluxdbusingheapster/ cc
Vish please take a look if you have cycles or reassign if there's someone with better context.
I looked at the panic and it was due to the last test (networking) timing out but still running. I think the fix is more in better cleanup between tests.
I just saw this... it's totally due to ginkgo's cleanup when a test times out. I can fix.
I will get this one.
Ugh, the thing ginkgo does when a test times out is totally lame...
Instead of working around this, I've filed I'm going to go back to a manual timeout on this test.
Change:
e2etestfiles "k8s.io/kubernetes/test/e2e/framework/testfiles" ) <del> //go:embed cluster-dns dra flexvolume guestbook kubectl sample-device-plugin scheduling/nvidia-driver-installer.yaml statefulset storage-csi </del> <ins> //go:embed dra flexvolume guestbook kubectl sample-device-plugin scheduling/nvidia-driver-installer.yaml statefulset storage-csi </ins> var e2eTestingManifestsFS embed.FS func GetE2ETestingManifestsFS() e2etestfiles.EmbeddedFileSource {

Discussion:
master-blocking: gce-cos-master-alpha-featuresKubernetes e2e suite:Failed runs: 09-16 09:58 CDT 09-15 23:41 CDT Both of these runs were on the same commit which also has passing builds. The test fails due to a , specifically when attempting to connect to the DNS backend service . The error indicates that the DNS backend service is either not running or not accessible on the specified address and port. This caused multiple retries in the test, with the pod failing to establish a connection to the backend service each time. As a result, the expected output "Hello World!" was not found in the logs, leading to the failure of the test. The service being unreachable could be due to several potential issues: misconfigured DNS, networking issues within the cluster, or the DNS backend service failing to start properly.Further investigation into the DNS service deployment and networking might be required to resolve this issue. There were two other failures ( , ) on the same commit that seemed to be related to cluster instance not being found: This caused failure when attempting to SSH into the instance and retrieve logs (kube-, , etc.). For those, the cluster setup (e2e-) likely failed, as no nodes were found, resulting in no instances being available. /sig network /kind flake cc:
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 network /kind flake
This test should not be running in this job, it was picked recently ! since we already have coverage I think is better to remove it, is also using images that the sources are not available anymore
Change:
vm.StorageProfile.DataDisks = &disks ctx, cancel := getContextWithCancel() defer cancel() <ins> // Invalidate the cache right after updating key := buildVmssCacheKey(nodeResourceGroup, ss.makeVmssVMName(ssName, instanceID)) defer ss.vmssVMCache.Delete(key) </ins> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk(%s)", nodeResourceGroup, nodeName, diskName) _, err = ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, vm) if err != nil { klog.Errorf("azureDisk - detach disk(%s) from %s failed, err: %v", diskName, nodeName, err) } else { klog.V(2).Infof("azureDisk - detach disk(%s) succeeded", diskName) <del> // Invalidate the cache right after updating key := buildVmssCacheKey(nodeResourceGroup, ss.makeVmssVMName(ssName, instanceID)) ss.vmssVMCache.Delete(key) </del> } return err

Discussion:
What happened: Azure Disks get randomly mounted in a way that makes them unusable, returning for every disk I/O operation. Affected Pods remain in until someone manually recreates them. What you expected to happen: Azure Disks are consistently usable by Pods inside which they are mounted. How to reproduce it: Create the following StatefulSet. Adjust the replicas and delete the associated Pods () until the problem occurs (i.e. some Pod ends up in ). <details</summary</details</brDefault StorageClass (as created by ACS-Engine): <details</summary</details</brAnything else we need to know?: Nodes were updated from 1.10.4 to 1.10.10, then from 1.10.10 to without a reboot. According to written by the issue is fixed, but I can still observe it quite often. Ref Azure/acs-engine Environment: Kubernetes version: v1.10.10 + Cloud provider or hardware configuration: Azure (westeurope) OS: Ubuntu 16.04.4 LTS Kernel: 4.13.0-1018-azure Install tools: ACS-Engine Others: /kind bug /sig storage /sig azure
In my current test environment: (pod uid is -f23b-11e8-bf38-) on the node Notice the mismatch between the disk referenced by lun0 () and the actual mount (). on the node
After deleting the failing Pod and waiting for its successful recreation: (pod uid is now -f247-11e8-bf38-) on the node This time disks are matching (). on the node
/assign
Change:
func (proxier *Proxier) isIPInExcludeCIDRs(ip net.IP) bool { // make sure it does not fall within an excluded CIDR range. for _, excludedCIDR := range proxier.excludeCIDRs { <del> // Any validation of this CIDR already should have occurred. _, n, _ := net.ParseCIDR(excludedCIDR) if n.Contains(ip) { </del> <ins> if excludedCIDR.Contains(ip) { </ins> return true } }

Discussion:
What would you like to be : Change excludeCIDRs from []string to []*IPNet in Proxier and perform the parsing at construction of Proxier. Why is this needed: This was proposed by over comments in Pr This improves the performance of isIPInExcludeCIDRs since the cost of parsing becomes one time.
/sig network /kind cleanup
/remove-kind feature
/triage unresolved I am a bot run by ‍
ping
Change:
</tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">revisionHistoryLimit</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 2.</p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10.</p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">integer (int32)</p></td> <td class="tableblock halign-left valign-top"></td>

Discussion:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps
Change:
fi # If there are no more remaining master replicas, we should delete all remaining network resources. <del> if [[ "${REMAINING_MASTER_COUNT}" == "0" ]]; then </del> <ins> if [[ "${REMAINING_MASTER_COUNT}" -eq 0 ]]; then </ins> # Delete firewall rule for the master, etcd servers, and nodes. delete-firewall-rules "${MASTER_NAME}-https" "${MASTER_NAME}-etcd" "${NODE_TAG}-all" # Delete the master's reserved IP

Discussion:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): upgrade test leak Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5 beta Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: kube- What happened: While doing manual upgrade testing, found that I couldn't start a new cluster as the existing firewall rules and external master ip address reservation where preventing kube-up from succeeding after running kube-down What you expected to happen: kube-down to clean up all cluster related resources How to reproduce it (as minimally and precisely as possible):
I tried this on a different GCP project and it didn't reproduce. I'm going to see if there's anything strange about my project.
Ack marking this as non-release-blocker
I think I found the problem. (from ) evaluates to false in bash on my mac. Changing it to fixes my issue. I'll send out a PR.
Change:
deps = [ "//staging/src/k8s.io/apimachinery/pkg/api/meta:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured/unstructuredscheme:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/json:go_default_library",

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : add --list option to kubectl annotate command Why is this needed: like kubectl label commandshow annotations quickly
/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. ‍
/assign
Change:
type RESTGracefulDeleteStrategy interface { // CheckGracefulDelete should return true if the object can be gracefully deleted and set // any default values on the DeleteOptions. <ins> // NOTE: if return true, `options.GracePeriodSeconds` must be non-nil (nil will fail), // that's what tells the deletion how "graceful" to be. </ins> CheckGracefulDelete(ctx context.Context, obj runtime.Object, options *metav1.DeleteOptions) bool }

Discussion:
Use apiserver extension(APIService) interface, impl its method to gracefully control resource deletion, when the field is nil, will lead to panic!! To first check if is nil, then get its value. Use apiserver extension(APIService) strategy, impl this function below will lead to panic: As the field is a int64 pointer, need to be careful when init the struct. 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 api-machinery
/triage accepted
Change:
imageutils.GetE2EImage(imageutils.Nonewprivs), imageutils.GetPauseImageName(), framework.GetGPUDevicePluginImage(), <del> "gcr.io/kubernetes-e2e-test-images/node-perf/npb-is-amd64:1.0", "gcr.io/kubernetes-e2e-test-images/node-perf/npb-ep-amd64:1.0", </del> <ins> "gcr.io/kubernetes-e2e-test-images/node-perf/npb-is:1.0", "gcr.io/kubernetes-e2e-test-images/node-perf/npb-ep:1.0", </ins> "gcr.io/kubernetes-e2e-test-images/node-perf/tf-wide-deep-amd64:1.0", )

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: test/e2enode/perf tests are referring to adm only images, this need to be replaced with multi-arch fat manifest images. ref:
/assign /sig node