jiebi/CodeConvo huggingface dataset:
Change:
func PidOf(name string) []int { pids := []int{} filepath.Walk("/proc", func(path string, info os.FileInfo, err error) error { <ins> if err != nil { return err } </ins> base := filepath.Base(path) // Traverse only the directories we are interested in if info.IsDir() && path != "/proc" {

Discussion:
https://k8s- Failed: TestPidOf {procfs}
https://k8s- Failed: TestPidOf {procfs}
could you take a look? Thanks.
https://k8s- Failed: TestPidOf {procfs}
https://k8s- Failed: TestPidOf {procfs}
I still am getting errors in this test even after rebasing-- https://k8s-
https://k8s- Failed: TestPidOf {procfs}
Looks like i read the godoc wrong and was returning the error causing the processing to stop. filed another PR
https://k8s- Failed: TestPidOf {procfs}
https://k8s- Failed: TestPidOf {procfs}
https://k8s- Failed: TestPidOf {procfs}
Change:
"versioned_client.go", ], tags = ["automanaged"], <del> visibility = [ "//build/visible_to:COMMON_testing", "//build/visible_to:pkg_kubectl_CONSUMERS", ], </del> deps = [ "//federation/apis/federation/v1beta1:go_default_library", "//pkg/api:go_default_library",

Discussion:
StatefulSet now as of 1.6. That means the TODO on can be fixed in 1.7. We could not fix it in 1.6 because that code is used by kubectl, which must work against servers that are one minor version ahead of or behind the client.
/cc
I am volunteered to take this job if no one start working on this.
I don't think anyone's working on it, so you are welcome to take it. Feel free to tag me as a reviewer. Thanks!
Change:
"k8s.io/kubernetes/pkg/controller" "github.com/golang/glog" <ins> "github.com/juju/ratelimit" </ins> ) type CertificateController struct {

Discussion:
Each node waiting for bootstrapping creates 1 line per 2-3s in the logs when the requesting client doesn't have access. It should not be logging at v(0), these are all v(4) level. We should be reporting these appropriately. I don't want a 5k node cluster showing this.
I'd like to fix it
Change:
// AUTO-GENERATED FUNCTIONS START HERE. DO NOT EDIT. var map_HTTPIngressPath = map[string]string{ "":         "HTTPIngressPath associates a path with a backend. Incoming urls matching the path are forwarded to the backend.", <del> "path":     "Path is matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a '/'. When unspecified, all paths from incoming requests are matched.", </del> <ins> "path":     "Path is matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a '/' and must be present when using PathType with value "Exact" or "Prefix".", </ins> "pathType": "PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by '/'. Matching isn  done on a path element by element basis. A path element refers is then  list of labels in the path split by the '/' separator. A request is an  match for path p if every p is an element-wise prefix of p of then  request path. Note that if the last element of the path is a substringn  of the last element in request path, it is not a match (e.g. /foo/barn  matches /foo/bar/baz, but does not match /foo/barbaz).n* ImplementationSpecific: Interpretation of the Path matching is up ton  the IngressClass. Implementations can treat this as a separate PathTypen  or treat it identically to Prefix or Exact path types.nImplementations are required to support all path types.", "backend":  "Backend defines the referenced service endpoint to which the traffic will be forwarded to.", }

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 --When I tried to use the default path I got . No error. According to the path is not needed. "When unspecified, all paths from incoming requests are matched." Create a ingress like so: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: brew Network plugin and version (if this is a network-related bug): N/A Others:
/sig network /area ingress It seems to be a problem of ingress and I suggest creating an issue in I find a similar one which is a little different there
We use - would this be a problem with the aws repo then?
/assign
So digging a bit here, the API docs needs to be improved. By the , is required if the PathPrefix is Exact or Prefix. To solve your issue specifically, you have two ways: Add that accepts ingress without paths Add and change PathPrefix to Prefix, so this becomes a catchAll I'll open a PR to fix the comment/docs. Thanks!
Thanks! In my case because I'm using ALB controller I had to use with prefix to get it working - see
/triage accepted PR will close this ;)
Change:
execFn func(), ) <ins> // MaintainObservations is a helper for maintaining statistics. MaintainObservations(stopCh <-chan struct{}) </ins> // Run monitors config objects from the main apiservers and causes // any needed changes to local behavior.  This method ceases // activity and returns after the given channel is closed.

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: Not observed yet, but deduced from analyzing the code. If a k/apiserver/pkg/util/flowcontrol/fairqueuing.QueueSet, whose metrics.TimedObserverPair is a pair of k/apiserver/pkg/util/flowcontrol/metrics.sampleAndWaterMarkHistograms, gets zero activity for a long while and then gets some activity, then the loop at will go through a lot of iterations, and do so with a lock held. What you expected to happen: No big hiccups in any scenario. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): branch 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:
/assign

<!-- 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: In reviewing I noticed an incorrect fake implementation of Interface. I looked at the comment on the Handle method, and noticed that it does not say when/how the is called. What you expected to happen: I expected the parameter to be as well documented as the others. How to reproduce it (as minimally and precisely as possible): Look at and see how it does not say when/whether/with-what-parameter-values is called. Anything else we need to know?: Environment: Kubernetes version (use ): current 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:
Any chance we could write a test for the interface which verifies correct plumbing?
/cc
: that should be do-able
Change:
} }) <del> ginkgo.It("verify PriorityClass endpoints can be operated with different HTTP methods", func() { </del> <ins> /* Release: v1.20 Testname: Scheduler, Verify PriorityClass endpoints Description: Verify that PriorityClass endpoints can be listed. When any mutable field is either patched or updated it MUST succeed. When any immutable field is either patched or updated it MUST fail. */ framework.ConformanceIt("verify PriorityClass endpoints can be operated with different HTTP methods", func() { </ins> // 1. Patch/Update on immutable fields will fail. pcCopy := pcs[0].DeepCopy() pcCopy.Value = pcCopy.Value * 10

Discussion:
The following PriorityClass endpoints was Promoted it 1.14 without Conformance tests, and remain untested: replace-, read-, patch-, list-, delete-collection- SchedulingV1PriorityClass According to this APIsnoop query, there are still some remaining PriorityClass endpoints which are untested. with this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints ! createSchedulingV1PriorityClass deleteSchedulingV1PriorityClass Promoted to Conformance 1.19 with /sig testing /sig architecture /area conformance
Is the ultimiate goal to use conformance tests to explicitly issue all CRUD requests against PriorityClass? And, is equivalent to "update PriorityClass"?
all APIs must have Conformance tests unless they are not eligible for Conformance due to the There is other APIGroups that have both Replace and Update as endpoints. That is the prerogative of the SIG to decide.
can you please point us to similar conformance tests used for core objects such as pods and nodes?
This is a life cycle test for Create, List, Update, Patch, DeleteCollection More can be found in the test/e2e folder. Also look for examples on the Conformance at previously Promoted Conformance test Reach out if we can help with more information on our approach to Conformance testing.
I remembered about this PR. Last week a few lines of code was to cover the last of the "Lease" endpoint group for conformance. The one file contain the Conformance tests for the complete life cycle of Lease endpoints.
/assign I will work on it.
/reopen Will monitor in test grid to move to Conformance after 2 weeks soak.
Reopened this issue. <detailsIn response to : /reopen Will monitor in test grid to move to Conformance after 2 weeks soak. </details
/triage accepted
Change:
f := input.f skipExecTest(input.resource.driver) <del> testScriptInPod(f, input.resource.volType, input.resource.volSource) </del> <ins> testScriptInPod(f, input.resource.volType, input.resource.volSource, input.config.NodeSelector) </ins> }) } <del> func testScriptInPod(f *framework.Framework, volumeType string, source *v1.VolumeSource) { </del> <ins> func testScriptInPod( f *framework.Framework, volumeType string, source *v1.VolumeSource, nodeSelector map[string]string) { </ins> const ( volPath = "/vol1" volName = "vol1"

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 pod is not created successfully, likely due to it being scheduled in a different zone from where the PD is provisioned. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
/sig storage /assign /priority critical-urgent
Change:
framework.Skipf("Runs only when number of nodes >= 2") } <del> ep := &eventPatterns{ reason:  "FailedMount", pattern: make([]string, 2)} ep.pattern = append(ep.pattern, "NodeSelectorTerm") ep.pattern = append(ep.pattern, "MountVolume.NodeAffinity check failed") </del> testVols := setupLocalVolumesPVCsPVs(config, DirectoryLocalVolumeType, config.node0, 1, immediateMode) testVol := testVols[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: Based on discussion , events can be throttled and should not be used to validate failure conditions in e2e tests. We should remove the event checks from subpath and local pv tests and just wait for pod failure. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
could you help look at this for local PV tests?
sure /assign
/area deflake
"Invalid AWS KMS key" also waits for an event

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: fsgroup tests are flaking 1-2 times a day: https://k8s- Some test logs: https://k8s- https://k8s-
could you take a look?
I'll look into this.
I found why the tests failed, see my analysis of logs: I created a PR () trying to fix the issue. I am still investigating kubelet and trying to reproduce the issue locally.
/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
/lifecycle frozen
Change:
var _ Interface = new(cadvisorUnsupported) <del> func New(address string, port uint, imageFsInfoProvider ImageFsInfoProvider, rootPath string) (Interface, error) { </del> <ins> func New(address string, port uint, imageFsInfoProvider ImageFsInfoProvider, rootPath string, usingLegacyStats bool) (Interface, error) { </ins> return &cadvisorUnsupported{}, nil }

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?: What happened: is failing with: What you expected to happen: The cross build should work,. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: It looks like this happened in , probably because we don't block the queue on cross :-( xref: /priority failing-test /sig release
Additionally ideally sig-release should for this job.
/assign
, is making a fix and then we'll look at making sure cross blocks PRs it runs against in the future.
Change:
to delete the secret, the deletion must succeed. release: v1.21 file: test/e2e/common/storage/secrets_volume.go <ins> - testname: StorageClass, lifecycle codename: '[sig-storage] StorageClasses CSI Conformance should run through the lifecycle of a StorageClass [Conformance]' description: Creating a StorageClass MUST succeed. Reading the StorageClass MUST succeed. Patching the StorageClass MUST succeed with its new label found. Deleting the StorageClass MUST succeed and it MUST be confirmed. Replacement StorageClass MUST be created. Updating the StorageClass MUST succeed with its new label found. Deleting the StorageClass via deleteCollection MUST succeed and it MUST be confirmed. release: v1.29 file: test/e2e/storage/storageclass.go </ins> - testname: 'SubPath: Reading content from a configmap volume.' codename: '[sig-storage] Subpath Atomic writer volumes should support subpaths with configmap pod [Conformance]'

Discussion:
[X] test approval issue : [X] test pr : [X] two weeks soak end date : 22 Sept 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three StorageClass endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 7 endpoints. The e2e logs for this test are listed below. This query shows the following StorageClass endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/sig storage
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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:
FilenameOptions resource.FilenameOptions ServerSideApply bool <ins> FieldManager    string </ins> ForceConflicts  bool OpenAPISchema    openapi.Resources

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: fails. What you expected to happen: I would expect the PatchOptions to not include FieldManager. The following fix will eliminate the problem. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.16 and 1.17 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 cli
cc
/wg apply
cc
I agree, we clearly missed that. Would you mind sending the fix in the form of a PR? Also please include a test, because that shouldn't have happened if I had tested my code properly :-(
Clearly we should also cherry-pick that into 1.17. I'll send the PR on Monday if you prefer! Thanks.
Ok, I will send a PR. However, I can't include a test immediately because I don't understand how the test works.
Thanks, I’ll try to show you how to get started!
Any update we clearly need this promptly since code-freeze is coming! Thanks.
I'll send a PR on Monday if you haven't! Thanks.
Sorry, I haven't started working on this test. Thanks.
Change:
return service } <del> func createLBServiceOrFail(clientset *fedclientset.Clientset, namespace, name string) *v1.Service { service, err := createLBService(clientset, namespace, name) </del> <ins> func createLBServiceOrFail(clientset *fedclientset.Clientset, namespace, name string, clusters fedframework.ClusterSlice) *v1.Service { service, err := createLBService(clientset, namespace, name, clusters) </ins> framework.ExpectNoError(err, "Creating service %q in namespace %q", service.Name, namespace) By(fmt.Sprintf("Successfully created federated service (type: load balancer) %q in namespace %q", name, namespace)) return service

Discussion:
In order to support running tests in parallel, we randomized NodePort selection. There appears to be some evidence that this is not sufficient and is causing e2e test flakes: https://k8s-
Hi, As a need contributor, I'm interesting of solving this issue. I already check the current code, and propose to retry the service creation until success or all possible ports (between FederatedSvcNodePortFirst and FederatedSvcNodePortLast) have been tried. If this approach is fine for you, I can submit a PR soon.
How do you plan to check if the NodePorts are available? In our presubmit test environment, tests run across many instances of federation control planes in parallel, but share the same underlying clusters. So this approach might be viable depending on how and where you plan to check for these used NodePorts.
my approach for getting an available port is a "Dummy" approach: create a list of possible available port, get one of them randomly, then try to create the Service. If Service creation failed. try to use another possible available port, until service creation success or all possible available ports have been tested.
Sounds reasonable to me. Go for it. A couple of caveats: need to create a real list, you could just use the range boundaries. careful about service creation failure. You need to check if the service shard creation failed in the underlying clusters and rollback all those shards before retrying.
thanks for the caveats, I will do soon a PR.
Hi, what is the state of this issue? Is working in this issues with the others issues related to e2e tests?
has a PR to fix this issue -
Change:
errorType:   field.ErrorTypeInvalid, errorDetail: "must be a valid seccomp profile", }, <ins> "invalid seccomp allow any default profile": { psp:         invalidSeccompAllowAnyDefault, errorType:   field.ErrorTypeInvalid, errorDetail: "must be a valid seccomp profile", }, </ins> "invalid seccomp allowed profile": { psp:         invalidSeccompAllowed, errorType:   field.ErrorTypeInvalid,

Discussion:
It should be possible to create a PodSecurityPolicy with zero restrictions. This was the intent with the (a.k.a. "AllowAny") allowed seccomp profile, but it is rejected during the validation phase. /kind bug
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/auth: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
kl.updatePodCIDR(node.Spec.PodCIDR) <del> if err := kl.setNodeStatus(node); err != nil { return err } </del> <ins> kl.setNodeStatus(node) </ins> // Patch the current status on the API server updatedNode, err := nodeutil.PatchNodeStatus(kl.kubeClient, types.NodeName(kl.nodeName), originalNode, node) if err != nil {

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): 1.3.8 custom build - the code seems to still be in place in master. Environment: Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): VERSION="14.04.5 LTS, Trusty Tahr" Kernel (e.g. ): 4.4.0-38-generic ~14.04.1-Ubuntu SMP Tue Sep 6 17:20:43 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: Custom Others: What happened: When the OpenStack Nova API is not accessible Nodes are marked as "NotReady" The OpenStack cloud providers seems to call Nova on a schedule to get information. If the API is not contactable, kubelet fails to call back to the masters, and gets marked as NotReady. Masters also call the Nova API, and when it fails, it can mark all nodes as NotReady. What you expected to happen: Nothing - the cluster should still work, regardless of Nova's API How to reproduce it (as minimally and precisely as possible): Install Kubernetes using the OpenStack provider. On the OpenStack controller stop the nova-api process.
Change:
err = pd.mounter.Mount(globalPDPath, pd.GetPath(), "", mount.FlagBind|flags, "") if err != nil { os.RemoveAll(pd.GetPath()) <ins> // TODO: we should really eject the attach/detach out into its own control loop. detachDiskLogError(pd) </ins> return err }

Discussion:
Repro: Create a pod that attempts to mount a GCE PD that is mis-formatted Delete the pod Expected: GCE PD should be detached Observed: GCE PD is not detached.
Chatted with offline and understand the problem with more detail: The basic problem is when filesystem on PD is unformatted, the mount is going to fail. Kubernetes doesn't do cleanup by detaching the PD. Two potential solutions were proposed: 1) use built-in utility: safeformatand_mount in GCE image to format and mount PD to avoid extra step to format the PD disk. 2) Handle mount failure properly. I think we might need handle both anyway. Brendan mentioned that you are looking at a potential new controller for PD, whose responsible is attaching and detaching PD disks. Do you have any latest status on this topic?
No latest status. I haven't done any actual work on it yet. The idea would be to scan the pods assigned to each node, and attaches (or detaches) any PDs that the node needs (or no longer needs). I'm still coming up to speed on a lot of the architectural concepts, so I'd love some guidance.
Now that Tim's volume re-factor has gone in, I'm going to re-visit this issue. Assigning to me.