jiebi/CodeConvo huggingface dataset:
Change:
return nil } if err != nil { <del> klog.V(5).Infof("Error getting PVC %q (uid: %q) from informer : %v", util.GetPersistentVolumeClaimQualifiedName(pvc), pvc.UID, err) </del> <ins> klog.V(5).Infof("Error getting PVC %q from informer : %v", key, err) </ins> return err } pv, err := expc.getPersistentVolume(ctx, pvc) if err != nil { <del> klog.V(5).Infof("Error getting Persistent Volume for PVC %q (uid: %q) from informer : %v", util.GetPersistentVolumeClaimQualifiedName(pvc), pvc.UID, err) </del> <ins> klog.V(5).Infof("Error getting Persistent Volume for PVC %q (uid: %q) from informer : %v", key, pvc.UID, err) </ins> return err } if pv.Spec.ClaimRef == nil || pvc.Namespace != pv.Spec.ClaimRef.Namespace || pvc.UID != pv.Spec.ClaimRef.UID { <del> err := fmt.Errorf("persistent Volume is not bound to PVC being updated : %s", util.ClaimToClaimKey(pvc)) </del> <ins> err := fmt.Errorf("persistent Volume is not bound to PVC being updated : %s", key) </ins> klog.V(4).Infof("%v", err) return err }

Discussion:
I migrated an existing EBS volume from in-tree plugin to external aws-ebs-csi-driver (). Resizing PVC twice in 6 hour window causes kube-controller-manager to crash. Exception message: Kube-controller-manager shouldn't crash in such case. If external aws-ebs-csi-driver fails to provision the pvc it should just log an warning or error and continue operating as usual running cluster version 1.22.9 using in-tree aws ebs driver. pvc: Install aws-ebs-csi-driver following featureGate CSIMigrationAWS on all cluster components (with draining nodes before enabling featureGate on kubelets - according to warning ) we have ebs volume that has been migrated to aws-ebs-csi-driver. pvc by increasing .spec.resources.request.storage to 2Gi. PVC, PV and EBS volume are correctly resized. once again not later than 6 hours after first resize. Increase .spec.resources.request.storage to 3Gi. Now kube-controller-manager throws an exception and crashes: EBS CSI Driver logs: I tried also enabling alpha featureGate InTreePluginAWSUnregister but the issue still occurs. <details</details<detailsAWS </details<details</details<details</details<detailsdocker </details<detailsaws-ebs-csi-driver version 1.10.0 </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
/sig cloud-provider
/sig storage some situation where the sync loop passes a nil parameter to
/assign
SetClaimResizer may return nil pvc and non-nil error, ClaimToClaimKey naively assumes non-nil as described above, will create PR
But the posted bug is I think 1.22 specific and should never happen on master or 1.24 and hence this fix against master is kind of okay and should fix the issue but at the same time code in is still kinda broken in 1.22 because it returns if patching fails.
Change:
}, scheme.ParameterCodec) var stdout, stderr bytes.Buffer <ins> Logf("ExecWithOptions: execute(POST %s %s)", req.URL()) </ins> err = execute("POST", req.URL(), config, options.Stdin, &stdout, &stderr, tty) if options.PreserveWhitespace { return stdout.String(), stderr.String(), err }

Discussion:
We should fine grained debug statements to ExecWithOptions in the framework class , so that in tests where theres alot of execs where hangs can happen i.e. on windows, we can see where tests are getting clogged up. Mostly i want this for , but i suppose its a generic improvement
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 testing /good-first-issue
This request has been marked as suitable for new contributors. 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 : /sig testing /good-first-issue 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
/assign
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]:
/remove-lifecycle stale
Change:
err := store.Delete(ctx, tt.key, out, nil, storage.ValidateAllObjectFunc, nil) if tt.expectNotFoundErr { if err == nil || !storage.IsNotFound(err) { <del> t.Errorf("%s: expecting not found error, but get: %s", tt.name, err) </del> <ins> t.Errorf("expecting not found error, but get: %s", err) </ins> } return } if err != nil { <del> t.Fatalf("%s: Delete failed: %v", tt.name, err) </del> <ins> t.Fatalf("Delete failed: %v", err) </ins> } <del> ExpectNoDiff(t, fmt.Sprintf("%s: incorrect pod:", tt.name), tt.expectedObj, out) </del> <ins> // We expect the resource version of the returned object to be // updated compared to the last existing object. if storedObj.ResourceVersion == out.ResourceVersion { t.Errorf("expecting resource version to be updated, but get: %s", out.ResourceVersion) } out.ResourceVersion = storedObj.ResourceVersion ExpectNoDiff(t, "incorrect pod:", tt.expectedObj, out) </ins> }) } }

Discussion:
While working on generalizing tests to somehow better define spec for storage interface (and share them across all implementation of storage.interface - in particular etcd3 and watchcache), I found an unexpected inconsistency in Delete operation in etcd3. What is happening is that it effectively returns the state of the object from just before the deletion: However, this is inconsistent with how our watch is working, which is returning the state of the object from just before the deletion, but it sets the RV to the moment of deletion (which Delete call isn't doing). This sounds like a bug to me, but given this is a long-standing behavior we may need to take additional care when fixing this. /kind bug /sig api-machinery /priority important-soon /cc
I opened as a fix for it.
/triage accepted
Change:
"sync" "time" <ins> "github.com/aws/aws-sdk-go/aws" </ins> "github.com/aws/aws-sdk-go/aws/awserr" "github.com/aws/aws-sdk-go/aws/request" "github.com/golang/glog"

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: See in : https://k8s- /cc Fixed in
/sig aws
Add /priority critical-urgent since marked it as a release blocker.
Ping! Release team here. This issue doesn't have any associated PRs which are passing tests. As a reminder, 1.9 Code Slush is on the 20th, and Code Freeze is on the 22nd. Do you think you'll have a working fix by then? If you plan for this fix to go into 1.9, the issue needs to be approved, and approved for the milestone.
the associated PR is . It needs another look from .
Peter, i just nudged that along.
yeah I see your and . Thanks Davanum!
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
Addresses:  []string{"1.2.3.6", "1.2.3.7"}, Conditions: discoveryv1.EndpointConditions{Ready: utilpointer.BoolPtr(true)}, TargetRef:  &corev1.ObjectReference{Kind: "Pod", Name: "test-124"}, <ins> NodeName:   utilpointer.StringPtr("node-2"), </ins> }, }, Ports: []discoveryv1.EndpointPort{

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 --panic as below when an Endpoint doesn't have zone. should print zone as if an Endpoint's zone is unset. not set "" for Nodes. Pods and export them as a service. kubectl to describe the corresponding EndpointSlice. Kubernetes version (use ): v1.21.0 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 network /sig cli /assign
Change:
} func (cm *containerManagerImpl) GetCPUs(podUID, containerName string) []int64 { <del> return cm.cpuManager.GetCPUs(podUID, containerName).ToSliceNoSortInt64() </del> <ins> if cm.cpuManager != nil { return cm.cpuManager.GetCPUs(podUID, containerName).ToSliceNoSortInt64() } return []int64{} </ins> } func (cm *containerManagerImpl) GetAllocatableCPUs() []int64 { <del> return cm.cpuManager.GetAllocatableCPUs().ToSliceNoSortInt64() </del> <ins> if cm.cpuManager != nil { return cm.cpuManager.GetAllocatableCPUs().ToSliceNoSortInt64() } return []int64{} </ins> } func (cm *containerManagerImpl) ShouldResetExtendedResourceCapacity() bool {

Discussion:
Iff the cpumanager feature gate (default: enabled) is explicitely disabled, calling podresources API causes a NPE in the kubelet. The stacktrace looks like This applies to any podresources API (either or ) Only triggers if the cpumanager feature gate is explicitely disabled (it is enabled by default in 1.20+) The podresources API should return either error or a valid value, not NPE. The simplest possible reproducer is probably to apply this patch And then run the podresources e2e tests We should probably add another e2e test to explicitly check this dlow Kubernetes version (use ): any since 1.20 (possibly introduced in commit ) Cloud provider or hardware configuration: any OS (e.g: ): any Kernel (e.g. ): any Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig node /triage accepted
possible workaround (not tested but everything suggests it should work) enable the cpumanager feature gate set the cpumanager policy to "none"
Change:
mountArgs = append(mountArgs, mountpoint) mountArgs = append(mountArgs, "-r") mountArgs = append(mountArgs, cephfsVolume.path) <ins> mountArgs = append(mountArgs, "--id") mountArgs = append(mountArgs, cephfsVolume.id) </ins> glog.V(4).Infof("Mounting cmd ceph-fuse with arguments (%s)", mountArgs) command := exec.Command("ceph-fuse", mountArgs...)

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: I tried to use pvs provisioned by the cephfs storageclass build from PV and pvc are OK but it failed when mounting. here is the output of the ceph-fuse mount command: I try the ceph-fuse mounting outside kubernetes environment, and found that I have to pass the --id argument to make ceph-fuse work correctly: so I add the --id option in file on line 401: and cephfs volumes can mount corretly with ceph-fuse then. Anything else we need to know?: My kubernetes cluster version is v1.6.7, running on arm64 servers, with ceph version 10.1.2, the kernel version is 4.4.58 . I backported the latest version to mount cephfs volumes with ceph-fuse.
/sig storage
Does this problem still exist in the latest k8s version?
yes, I've tested on kubernetes v1.10.0-alpha.3 with ceph version 10.2.10 and the problem still exists
OK, let me see it ,and feedback soon. =)
Hi, one question is that do you use 'admin' as user or other user to mount cephfs by fuse ?
when no "--id" specified, the default user is admin, which will result in bug when user is not admin.
/assign
Change:
}, wantErr: false, }, <ins> { name: "DualSocketHT - non unique Core'ID's", args: &cadvisorapi.MachineInfo{ NumCores: 12, Topology: []cadvisorapi.Node{ {Id: 0, Cores: []cadvisorapi.Core{ {Id: 0, Threads: []int{0, 6}}, {Id: 1, Threads: []int{1, 7}}, {Id: 2, Threads: []int{2, 8}}, }, }, {Id: 1, Cores: []cadvisorapi.Core{ {Id: 0, Threads: []int{3, 9}}, {Id: 1, Threads: []int{4, 10}}, {Id: 2, Threads: []int{5, 11}}, }, }, }, }, want: &CPUTopology{ NumCPUs:    12, NumSockets: 2, NumCores:   6, CPUDetails: map[int]CPUInfo{ 0:  {CoreID: 0, SocketID: 0}, 1:  {CoreID: 1, SocketID: 0}, 2:  {CoreID: 2, SocketID: 0}, 3:  {CoreID: 3, SocketID: 1}, 4:  {CoreID: 4, SocketID: 1}, 5:  {CoreID: 5, SocketID: 1}, 6:  {CoreID: 0, SocketID: 0}, 7:  {CoreID: 1, SocketID: 0}, 8:  {CoreID: 2, SocketID: 0}, 9:  {CoreID: 3, SocketID: 1}, 10: {CoreID: 4, SocketID: 1}, 11: {CoreID: 5, SocketID: 1}, }, }, wantErr: false, }, { name: "OneSocketHT fail", args: &cadvisorapi.MachineInfo{ NumCores: 8, Topology: []cadvisorapi.Node{ {Id: 0, Cores: []cadvisorapi.Core{ {Id: 0, Threads: []int{0, 4}}, {Id: 1, Threads: []int{1, 5}}, {Id: 2, Threads: []int{2, 2}}, // Wrong case - should fail here {Id: 3, Threads: []int{3, 7}}, }, }, }, }, want:    &CPUTopology{}, wantErr: true, }, { name: "OneSocketHT fail", args: &cadvisorapi.MachineInfo{ NumCores: 8, Topology: []cadvisorapi.Node{ {Id: 0, Cores: []cadvisorapi.Core{ {Id: 0, Threads: []int{0, 4}}, {Id: 1, Threads: []int{1, 5}}, {Id: 2, Threads: []int{2, 6}}, {Id: 3, Threads: []int{}}, // Wrong case - should fail here }, }, }, }, want:    &CPUTopology{}, wantErr: true, }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: CPU Manager uses topology from cAdvisor which uses which is different from in terms of coreID's. assigns coreID's in unique manner (platform-wise) whereas has coreID's from CPU registers which are unique only on socket level. This causes some unexpected cpu assignment on platforms with more than one socket. All tests written all "false positive" Example output: From What you expected to happen: Fix either by changing the way CPU manger sees topology (use ) or redesign CPU Manager to handle coreID's as socket only unique How to reproduce it (as minimally and precisely as possible): kubelet on dual socket node G pod that requests 2 cores pod gets 2 cores on different sockets
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig node
Change:
Kind string // Name is empty for some verbs, but if the request directly indicates a name (not in body content) then this field is filled in. Name string <del> // Parts are the path parts for the request relative to /{resource}/{name} </del> <ins> // Parts are the path parts for the request, always starting with /{resource}/{name} </ins> Parts []string <ins> // Raw is the unparsed form of everything other than parts. // Raw + Parts = complete URL path Raw []string } // URLPath returns the URL path for this request, including /{resource}/{name} if present but nothing // following that. func (info APIRequestInfo) URLPath() string { p := info.Parts if n := len(p); n > 2 { // Only take resource and name p = p[:2] } return path.Join("/", path.Join(info.Raw...), path.Join(p...)) </ins> } type APIRequestInfoResolver struct {

Discussion:
The apiserver proxy rewrites links to the form "/proxy/ns/default/...": But this form stopped working recently, seemingly around The "/proxy/ns/default/..." form always returns "404: Page Not Found", similar to the problem seen in If you remove "/ns/default" from the URL, it works.
/cc
I can investigate this as well.
I see the issue, sending a PR.
The proxy path needs to be built with knowledge of the apiversion of the incoming proxy request, and it needs to be updated to use the knowledge from the restmapper. This is a little trickier than I have time for right now, but it should definitely not be hardcode appending the /ns form. Not clear why this is not also caught by our test case. I can try and look at this more in the AM unless someone else wants to take a look in interim. /cc
Let me steal this one from you, I think I can fix it.
Have at it. /cc me on your PR
Sorry, I see you've already got a PR out!
No problem. I would be happy if you finished my PR relative to the commit I started. It will be a few days before I can go back to looking at this issue. I think v1beta1/v1beta2 proxy urls in go-restful need to always but the namespace scope in the path as the ultimate fix. I do want the proxy to have access to the restmapper per my PR. ----- Original Message ----- From: "Daniel Smith" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Friday, February 13, 2015 4:56:19 PM Subject: Re: [kubernetes] apiserver proxy stopped accepting namespaces () Sorry, I see you've already got a PR out! Reply to this email directly or view it on GitHub:
Any updates ?
This is breaking monitoring since it requires the proxy. Bumping up the priority to P0.
Sorry for dropping this. Working on a fix.
Change:
var _ volume.VolumePlugin = &downwardAPIPlugin{} <del> var wrappedVolumeSpec = volume.Spec{ Volume: &api.Volume{VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{Medium: api.StorageMediumMemory}}}, </del> <ins> func wrappedVolumeSpec() volume.Spec { return volume.Spec{ Volume: &api.Volume{VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{Medium: api.StorageMediumMemory}}}, } </ins> } func (plugin *downwardAPIPlugin) Init(host volume.VolumeHost) error {

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
"time" "k8s.io/api/core/v1" <ins> schedulerapi "k8s.io/api/scheduling/v1beta1" "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields"

Discussion:
https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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:
}) /* <del> Testname: var-expansion-subpath-lifecycle Description: Verify should not change the subpath mount on a container restart if the environment variable changes 1.	valid subpathexpr starts a container running 2.	test for valid subpath writes 3.	container restarts 4.	delete cleanly </del> <ins> Release : v1.19 Testname: VolumeSubpathEnvExpansion, subpath lifecycle Description: Verify should not change the subpath mount on a container restart if the environment variable changes 1.	valid subpathexpr starts a container running 2.	test for valid subpath writes 3.	container restarts 4.	delete cleanly </ins> */ <del> ginkgo.It("should not change the subpath mount on a container restart if the environment variable changes [sig-storage][Slow]", func() { </del> <ins> framework.ConformanceIt("should not change the subpath mount on a container restart if the environment variable changes [sig-storage][Slow]", func() { </ins> suffix := string(uuid.NewUUID()) podName := fmt.Sprintf("var-expansion-%s", suffix)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind api-change /sig storage /sig node /sig testing Description: Promote e2e tests for VolumeSubpathEnvExpansion to Conformance as it is GA approved. Related Issues: GA Upgrade: Feature Request: KEP:
/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