jiebi/CodeConvo huggingface dataset:
Change:
// NodeMetrics sets resource usage metrics of a node. type NodeMetrics struct { <del> metav1.TypeMeta   `json:",inline"` </del> <ins> metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata // +optional </ins> metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"` // The following fields define time interval from which metrics were

Discussion:
no explanation for metadata filed of NodeMetrics/PodMetrics, code: should be like $ kubectl explain NodeMetrics KIND: NodeMetrics VERSION: DESCRIPTION: NodeMetrics sets resource usage metrics of a node. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. usage <map[string]string-required- The memory usage is the memory working set. window <string-required- and $ kubectl explain PodMetrics KIND: PodMetrics VERSION: DESCRIPTION: PodMetrics sets resource usage metrics of a pod. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: containers <[]Object-required- Metrics for all containers are collected within the same time window. kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. window <string-required- able to see the explanation for metadata filed of NodeMetrics/PodMetrics Kubernetes Version: v1.22.0-rc.0+
/sig instrumentation
/kind documentation /assign /triage accepted
Change:
case *metav1beta1.Table: includesTable = true <del> if err := NewTableSorter(t, r.field).Sort(); err != nil { continue </del> <ins> if sorter, err := NewTableSorter(t, r.field); err != nil { return err } else if err := sorter.Sort(); err != nil { return err </ins> } default: includesRuntimeObjs = true

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: seems to have regressed in v1.13.0 and no longer sorts by creation timestamp. What you expected to happen: should sort by creation timestamp. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: N/A Environment: Kubernetes version (use ): <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
/assign
bisected to () /assign
opened to fix
/assign
Change:
- apiGroups: ["cloud.google.com"] resources: ["backendconfigs"] verbs: ["get", "list", "watch", "update", "create", "patch"] <ins> - apiGroups: ["networking.gke.io"] resources: ["servicenetworkendpointgroups"] verbs: ["get", "list", "watch", "update", "create", "patch"] </ins>

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which test(s) are failing: Since when has it been failing: The full testgrid history is red, but it has been failing at least since 5/29 Testgrid link: Reason for failure: Anything else we need to know: Originally these failures were due to an rbac permission issue (see: ), but now that that has been resolved, the tests are still not passing.
/sig network
adding to the milestone for investigation, since ingress was touched this release /milestone v1.19
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
what is the difference between that job and (which seems to be mostly passing)?
/assign
Also assigning since I think he's already looking into this: /assign
Oh nice, prow can actually assign me now
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Sorry for the delay. This has been triaged. The actual issue is that: system:controller:glbc rbac needs patch permissions for "ingresses/status" in I will send a PR for the fix. /remove-triage unresolved
^ PR
looks like that resolved almost all the failures. is still failing
Nice! Looks like this failure is caused by relying on the old static IP behavior. We used to allocate one if the specified one did not exist. I will send a PR to update the test.
can we close this out with ?
Yes, latest run was green:
/reopen Can this be reviewed again please? cc
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
seems to be a RBAC issue?
/cc did ingress-gce just start expecting access to this resource recently? does the RBAC role at need to be updated?
Hi, I've filed to address the issue.
Change:
case status.State.Running != nil: return false, fmt.Errorf("subpath container unexpectedly became running") case status.State.Terminated != nil: <ins> if status.State.Terminated.ExitCode != 0 && allowContainerTerminationError { return true, nil } </ins> return false, fmt.Errorf("subpath container unexpectedly terminated") case status.State.Waiting != nil: if status.State.Waiting.Reason == "CreateContainerConfigError" &&

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: The read only sig-storage tests validate that Pods can come up when readOnly is set. But it doesn't actually validate that the container cannot write to the volume. What you expected to happen: Tests should validate that the container cannot write to readonly volumes. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
can this issue be closed after your last PR or is there more to work on? If yes I'd like to know what's left because I'm looking for something to work on
I think we should actually reinstate the test case I removed and enhance it to handle the two scenarios I mentioned. It would also be good to see if we have other readOnly test cases that could be enhanced as well
Thanks ! I have a few questions: 1) how do I run the tests in locally? and 2) how can I assert writing to volume has failed? Thank you in advance!!
Change:
} func newController(nodeNames []string, batchPeriod time.Duration) (*fake.Clientset, *endpointSliceController) { <del> client := newClientset() </del> <ins> client := fake.NewSimpleClientset() </ins> informerFactory := informers.NewSharedInformerFactory(client, controller.NoResyncPeriodFunc()) nodeInformer := informerFactory.Core().V1().Nodes() indexer := nodeInformer.Informer().GetIndexer()

Discussion:
The controllers can create a second EndpointSlice after an immediate sync if the first EndpointSlice they created is not in the cache yet. Here's what can happen: gets event that triggers sync for Service syncs and creates EndpointSlice gets event that triggers sync for same Service syncs and creates EndpointSlice (the slice created in 2 has not made it to the cache yet) A single EndpointSlice to be created. Run integration tests hundreds of times that involve 2 consecutive events that will trigger a sync. Example: /assign /sig network
/triage accepted
/cc
When this bug is fixed, we'll need to rollback
just amend it in the PR that fix the bug, so we merge all together
Change:
nodeMonitorGracePeriod time.Duration, nodeStartupGracePeriod time.Duration, nodeMonitorPeriod time.Duration) *NodeController { <ins> eventBroadcaster := record.NewBroadcaster() recorder := eventBroadcaster.NewRecorder(api.EventSource{Component: "controllermanager"}) if kubeClient != nil { glog.Infof("Sending events to api server.") eventBroadcaster.StartRecordingToSink(kubeClient.Events("")) } else { glog.Infof("No api server defined - no events will be sent to API server.") } </ins> return &NodeController{ cloud:                   cloud, matchRE:                 matchRE,

Discussion:
/cc
Is this from head? I've never seen this before, maybe changed anything recently. Anyway, the code in question will be deleted by
I saw this in the Travis run for an unrelated PR (Kubelet test refactoring). If it's going away, then that's ho we'll fix it :)
Yup. It'll go away. I'll assign it to myself - I'll run test few times after to make sure it's gone.
another example: https://travis-
Just hit this again: https://travis-
I was hoping we could finish getting rid of this code this week, which is why I had been ignoring this. But we ran out of time and Poland has a holiday on Monday, so I guess we need to fix this race. I'll take a look.
Thanks. This is becoming a real nuisance that is masking other failures.
To repro I assume I just type the commands from Travis, e.g. the shell stuff in https://travis- ?
Never mind, I got it. Though the first time I ran it all the tests passed.
I don't think the failure is deterministic, but yes.
This is super annoying, it happens way too much of the time...
Sigh, I was hoping we can get rid of the code this week. I think the problem comes from someone changes the event recording. I'll send a PR
It seems to be basically always failing now, except when some other flake fails first.
It would be fine with me if we just temporarily disabled event generation there.
If I'm reading the stack traces correctly, what's going on is that NewNodeController [] calls StartRecordingToSink() [] which calls StartEventWatcher() which calls eventHandler() which calls StartRecordingToSink() which calls sink.Create() which is Create() in , which appends to c.Fake.Actions. At the same time, the last line of the test tries to print "item.fakeNodeHandler.Actions" and these are presumably the same variable. I'm not sure why these are running at the same time, though.
+1 to Braians idea to temporary disable event generation.
Re-titled issue.
Re-titled issue.
Change:
operator: "Exists" containers: - name: coredns <del> image: coredns/coredns:0.9.10 </del> <ins> image: coredns/coredns:1.0.1 </ins> imagePullPolicy: IfNotPresent resources: limits:

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG What happened: When CoreDNS is deployed by default using feature-gates of kubeadm, it does not log anything when processing a DNS query. That is due to change of log option of CoreDNS in latest version. that version was bumped up in kubeadm, but the manifest was not adapted to the new log option. initial change of 'log stdout' in CoreDNS : version of CoreDNS 1.0.0 bumped into Kubeadm : NOTE: I guess we should also changed manifests for kube-up : see The change in manifest expected is to remove the option "stdout" in the line "log ...". As it is now interpreted as a scope of domain to log. Invalid manifest: Environment: Kubernetes version (use ): 1.9 and MAIN Cloud provider or hardware configuration: any Install tools: kubeadm, kube-up the configmap for coredns kubectl get configmaps -n kube-system coredns -o yaml kubectl replace -f - the coredns deployment kubectl scale deployment --replicas=0 -n kube-system coredns kubectl scale deployment --replicas=1 -n kube-system coredns
/cc /sig network
NOTE: only log is impacted. CoreDNS working as expected.
/cc
I have a question : the initial manifest is done for the image 0.9.10 of CoreDNS. Bumping the version of CoreDNS was done by changing the version in file (see ) which means that the image's version is STILL 0.9.10 in the manifests ... and the corefile config is correct against the version of the manifest. QUESTION: when modifying the , is there a way to upgrade the manifest by program ? I guess at the time the new version number is applied on the manifest ...
thanks for reporting this! I send PR to update the Corefile. I don't think of a way so far. I guess we can't unless there is a way to get the Corefile from some place of upstream (CoreDNS).
Change:
vm, err := getVirtualMachineByName(i.cfg, ctx, c, name) if err != nil { <ins> if _, ok := err.(*find.NotFoundError); ok { return "", cloudprovider.InstanceNotFound } </ins> return "", err }

Discussion:
ExternalID/InstanceID do not return 'cloudprovider.InstanceNotFound' error when the VM is not found. This can occur when a node VM is deleted entirely. In this case InstanceID method would throw an nil pointer exception here: since returned error here: is not being handled, vm would be nil. vm object is then dereferenced in getVirtualMachineManagedObjectReference func. In ExternalID method, the error is being handled by just passing it up. Node controller then prints out error and continues: e.g. ExternalID/InstanceID should handle the 'nod found' error being returned from vCenter and return 'cloudprovider.InstanceNotFound'.
Change:
import ( "testing" <ins> "github.com/stretchr/testify/assert" </ins> discovery "k8s.io/api/discovery/v1beta1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/types" </ins> ) func TestEndpointSliceTrackerUpdate(t *testing.T) {

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 endpointSliceTracker creates a set of resource versions for each service, the resource versions in the set could be deleted when endpointslices are deleted, but the set and its key in the map is never deleted, leading to memory leak. What you expected to happen: The set of resource versions should be delete from endpointSliceTracker when the service is deleted. Environment: Kubernetes version (use ): 1.18.5
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
/cc
Change:
if err != nil { return []*v1.Pod{}, err } <del> // TODO: Do we need to copy here? result := make([]*v1.Pod, 0, len(pods)) for i := range pods { result = append(result, &(*pods[i])) } return result, nil </del> <ins> return pods, nil </ins> } func (dc *DisruptionController) worker() {

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.): DisruptionController getPodsForPdb Is this a BUG REPORT or FEATURE REQUEST? FEATURE REQUEST in we have function return pods using . but at the end we perform a copy of the pod array that we listed with : this is not necessary cc
/assign
/kind enhancement
Change:
func (a *azureDiskAttacher) WaitForAttach(spec *volume.Spec, devicePath string, _ *v1.Pod, timeout time.Duration) (string, error) { var err error <del> lun, err := strconv.Atoi(devicePath) </del> <ins> volumeSource, err := getVolumeSource(spec) </ins> if err != nil { <del> return "", fmt.Errorf("azureDisk - Wait for attach expect device path as a lun number, instead got: %s (%v)", devicePath, err) </del> <ins> return "", err </ins> } <del> volumeSource, err := getVolumeSource(spec) </del> <ins> diskController, err := getDiskController(a.plugin.host) </ins> if err != nil { return "", err } <ins> nodeName := types.NodeName(a.plugin.host.GetHostName()) diskName := volumeSource.DiskName glog.V(5).Infof("azureDisk - WaitForAttach: begin to GetDiskLun by diskName(%s), DataDiskURI(%s), nodeName(%s), devicePath(%s)", diskName, volumeSource.DataDiskURI, nodeName, devicePath) lun, err := diskController.GetDiskLun(diskName, volumeSource.DataDiskURI, nodeName) if err != nil { return "", err } glog.V(5).Infof("azureDisk - WaitForAttach: GetDiskLun succeeded, got lun(%v)", lun) </ins> exec := a.plugin.host.GetExec(a.plugin.GetPluginName()) io := &osIOHandler{} scsiHostRescan(io, exec) <del> diskName := volumeSource.DiskName nodeName := a.plugin.host.GetHostName() </del> newDevicePath := "" err = wait.Poll(1*time.Second, timeout, func() (bool, error) { <del> if newDevicePath, err = findDiskByLun(lun, io, exec); err != nil { </del> <ins> if newDevicePath, err = findDiskByLun(int(lun), io, exec); err != nil { </ins> return false, fmt.Errorf("azureDisk - WaitForAttach ticker failed node (%s) disk (%s) lun(%v) err(%s)", nodeName, diskName, lun, err) }

Discussion:
<!-- 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: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This was introduced by following code change introduced in v1.10.0: candidate fix is here(only works on Linux, not a good solution): This issue is caused by PR: Environment: Kubernetes version (use ): v1.10 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Update: above fix does not work on Windows, I am still investigating a better solution. This issue is caused by updated after , related code is here: while should not be changed from LUN to real device path in azuredd since AttachDisk happens on master, is a LUN(Logical Unit Number) number after AttachDisk process in the beginning happens on agent node: on Linux node, could be ; while on Windows node, would be a disk number, when is recalled, it could not tell whether it's a LUN or a disk number (this is the key point).
thanks for issuing this problem. Could you submit a PR with your fix so that we can review it? Thanks!
finally I realized should not be used in func any more by referencing the gcepd code, PTAL , awsebs code should have same issue, I filed a aws_ebs issue here:
Change:
}) /* <ins> Release: v1.25 Testname: Jobs, manage lifecycle </ins> Description: Attempt to create a suspended Job which MUST succeed. Attempt to patch the Job to include a new label which MUST succeed. The label MUST be found. Attempt to replace the Job to include a

Discussion:
[x] Test approval issue : [x] Test PR : - Needed an update on the handling of anotations 27 March 2022 [x] Two weeks soak end date : 6 April 2022 [x] Test promotion PR : [x] Update Test PR: 15 April 2022 [x] Two weeks soak end date : 4 May 2022 with start of 1.25 [x] Update Test Promotion: According to these APIsnoop queries, there are still four remaining Job endpoints which are untested. Using a number of existing e2e test practices a new has been created for this job lifecycle test. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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
/reopen for tracking e2e testgrid and promotion PR
/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
Change:
// ReadPrivateKeyFromPEM is a helper function for reading a private key from a PEM-encoded file func ReadPrivateKeyFromPEM(data []byte) (interface{}, error) { <del> if key, err := jwt.ParseRSAPrivateKeyFromPEM(data); err == nil { return key, nil } if key, err := jwt.ParseECPrivateKeyFromPEM(data); err == nil { return key, nil </del> <ins> var block *pem.Block for { // read the next block block, data = pem.Decode(data) if block == nil { break } // get PEM bytes for just this block blockData := pem.EncodeToMemory(block) if key, err := jwt.ParseRSAPrivateKeyFromPEM(blockData); err == nil { return key, nil } if key, err := jwt.ParseECPrivateKeyFromPEM(blockData); err == nil { return key, nil } // tolerate non-key PEM blocks for compatibility with things like "EC PARAMETERS" blocks // originally, only the first PEM block was parsed and expected to be a key block </ins> } return nil, fmt.Errorf("data does not contain a valid RSA or ECDSA private key") }

Discussion:
Kubernetes version Serverversion 1.5.2 (running Hyperkube v1.5.2coreos.1 ()) Environment: Bare-Metal Coreos 1235.6.0 (Kernel 4.7.3-coreos-r2) What happened: kube-controller-manager with ecdsa key fails to start F0127 09:59:04. 1 ] error running controllers: Error reading key for service account token controller: error reading private key file data does not contain a valid RSA or ECDSA private key The key is valid (and works with e.g. the api-server) Command used to create the key:
the issue is the block. removing that (invoke openssl with to omit it from the start) will allow the key to be consumed. will fix in 1.6 to ignore that block when reading the private key block