jiebi/CodeConvo huggingface dataset:
Change:
newClaimArray("claim11-8", "uid11-8", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation), // Binding will be completed in the next syncClaim newClaimArray("claim11-8", "uid11-8", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation, annStorageProvisioner), <del> noevents, </del> <ins> []string{"Normal ProvisioningSucceeded"}, </ins> []reactorError{ // Inject error to the first // kubeclient.PersistentVolumes.Create() call. All other calls

Discussion:
is quite confusing when provisioning for a PVC fails and then succeeds: it shows the PVC as , i.e. everything is OK the last logged event is , i.e. something went wrong What of the above is correct? We should log also the success:
fixed by
Change:
value.Namespace = action.GetNamespace() limitRangeList.Items = append(limitRangeList.Items, value) } <del> // he always blocking before sending the signal <-unhold </del> <ins> // make the handler slow so concurrent calls exercise the singleflight time.Sleep(time.Second) </ins> return true, limitRangeList, nil })

Discussion:
pull-kubernetes-unit /cc /sig scalability
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
In local tests, he always passes, so I'll see if the problem is caused by the environment
If the lru cache exceeds 30 seconds, the cache will be invalidated, which will lead to unit test errors, and the problem will run normally again after retesting.
After I manually reduce an unhold <- struct{}{}, the same problem occurs, so it seems that the problem is caused by the cache being invalidated for more than 30 seconds. If the test doesn't complete in 30 seconds, then this is probably a machine performance issue
stress will hang after about a minute in my local test.
/cc
The issue is being fixed
Change:
The IP address on which to serve on. .PP <del> fB--api-prefixfP="/api/" </del> <ins> fB--api-prefixfP="/" </ins> Prefix to serve the proxied API under. .PP

Discussion:
Now that we've moved the experimental api to /apis/experimental... it's inaccessible from by default. We should fix that. who stepped on this earlier
security questions for you: this prefix was apparently in response to a security review quite some time ago. I don't understand how this adds much security. Can we just remove it? If not, is it acceptable to change the default from "/api/" to "/api", which would match both api locations? Otherwise we'll have to take a comma-separated list or something...
Ref
Oh, so this is not related to the security requests! And the original use case was just to re-root the URL path so it didn't interfere with static content. Sorry, I got confused because the last time I monkeyed with that, it was in conjunction with the allow/deny list that actually was the security request. In that case, let's see if we can change the default to "/", if that will break anything.
That change got introduced as part of to protect against XSRF in kubectl proxy. But I think the more important part of that change was that it disallows POST/PUT/PATCH by default. So as long as there is no state changing action outside of /api/ that can be triggered with a GET it should be safe to remove.
Change:
return WorkEstimate{Seats: maximumSeats} } <del> // TODO: For resources that implement indexes at the watchcache level, //  we need to adjust the cost accordingly </del> <ins> limit := numStored if utilfeature.DefaultFeatureGate.Enabled(features.APIListChunking) && listOptions.Limit > 0 && listOptions.Limit < numStored { limit = listOptions.Limit } </ins> var estimatedObjectsToBeProcessed int64 switch { case isListFromCache: <del> // if we are here, count is known estimatedObjectsToBeProcessed = count </del> <ins> // TODO: For resources that implement indexes at the watchcache level, //  we need to adjust the cost accordingly estimatedObjectsToBeProcessed = numStored case listOptions.FieldSelector != "" || listOptions.LabelSelector != "": estimatedObjectsToBeProcessed = numStored + limit </ins> default: <del> // Even if a selector is specified and we may need to list and go over more objects from etcd // to produce the result of size <limit>, each individual chunk will be of size at most <limit>. // As a result. the work estimate of the request should be computed based on <limit> and the actual // cost of processing more elements will be hidden in the request processing latency. estimatedObjectsToBeProcessed = listOptions.Limit if estimatedObjectsToBeProcessed == 0 { // limit has not been specified, fall back to count estimatedObjectsToBeProcessed = count } </del> <ins> estimatedObjectsToBeProcessed = 2 * limit </ins> } // for now, our rough estimate is to allocate one seat to each 100 obejcts that

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 --I noticed that does not make sense to me. Looking at how LIST requests are served (which is NOT easy, there is so much dependency injection), I concluded that the worst case number of objects touched in the apiserver equals the pagination limit only if all of the following are true. The LIST request is served from etcd rather than the watch cache. The pagination FeatureGate is enabled. The request has a specified limit and it is no greater than the number of objects in etcd (restricted by namespace if relevant). The request does not have a label selector or field selector. I expected the list work estimator to use the pagination limit only under the conditions listed above. 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:
I commented on the PR.
Thank you both Mike and Wojciech! /triage accepted
Change:
} // Create the container. <del> fClock.SetTime(time.Now()) </del> <ins> fClock.SetTime(time.Now().Add(-1 * time.Hour)) </ins> *expected.CreatedAt = fClock.Now().Unix() id, err := ds.CreateContainer("sandboxid", config, sConfig) // Set the id manually since we don't know the id until it's created.

Discussion:
Another flake i found earlier yesterday, just linking to it for posterity, not blocking me right now. TestContainerStatus
Could you post some error log here? I can't reproduce it with stress test
Hm, got one reproduce:
Change:
}, []string{"verb", "group", "version", "resource", "subresource", "scope", "component", "code"}, ) <ins> apiSelfRequestCounter = compbasemetrics.NewCounterVec( &compbasemetrics.CounterOpts{ Name:           "apiserver_selfrequest_total", Help:           "Counter of apiserver self-requests broken out for each verb, API resource and subresource.", StabilityLevel: compbasemetrics.ALPHA, }, []string{"verb", "resource", "subresource"}, ) </ins> kubectlExeRegexp = regexp.MustCompile(`^.*((?i:kubectl.exe))`) metrics = []resettableCollector{

Discussion:
Currently we don't have an easy way of determining what number of requests are apiserver self-requests. This has historically bitten us, since we used to have a 50(?) QPS limit on apiserver self-requests (which thus has been removed). Even so, it would be a good idea to know this generally, since this may be helpful in pinpointing performance regressions for apiserver. /sig api-machinery instrumentation
Can this issue be considered a newbie one? I'm hunting for issues which might be a good first PR.
In the triage meeting was mentioned that would be good to have similar issues to track other well known actors like controller-manager and kubelet. But let's keep this one for api-server calling itself to have it done. /cc
/cc
Change:
clset := release_1_3.NewForConfigOrDie(restclient.AddUserAgent(cfg, UserAgentName)) clusterClientSets = append(clusterClientSets, clset) } <ins> for i, cs := range clusterClientSets { if _, err := cs.Core().Namespaces().Get(f.Namespace.Name); errors.IsNotFound(err) { ns := &v1.Namespace{ ObjectMeta: v1.ObjectMeta{ Name: f.Namespace.Name, }, } if _, err := cs.Core().Namespaces().Create(ns); err != nil { framework.Logf("Couldn't create the namespace %s in cluster [%d]: %v", f.Namespace.Name, i, err) } framework.Logf("Namespace %s created in cluster [%d]", f.Namespace.Name, i) } else if err != nil { framework.Logf("Couldn't create the namespace %s in cluster [%d]: %v", f.Namespace.Name, i, err) } } </ins> }) AfterEach(func() { framework.SkipUnlessFederated(f.Client) <ins> for i, cs := range clusterClientSets { if err := cs.Core().Namespaces().Delete(f.Namespace.Name, &api.DeleteOptions{}); err != nil { framework.Failf("Couldn't delete the namespace %s in cluster [%d]: %v", f.Namespace.Name, i, err) } framework.Logf("Namespace %s deleted in cluster [%d]", f.Namespace.Name, i) } </ins> // Delete the registered clusters in the federation API server. clusterList, err := f.FederationClientset.Federation().Clusters().List(api.ListOptions{}) Expect(err).NotTo(HaveOccurred())

Discussion:
Federated service shards are created only in the clusters that have the specified namespace. To fix this problem we need to create the namespace on-demand while creating the federated service shards. cc
As discussed, we explicitly decided not to do it this way. In Kubernetes, when one creates an entity, if the namespace does not exist, the creation call fails. What we need to do for v1.3 is pre-create the test namespace in all of the underlying clusters as part of the e2e test turnup.
Change:
func TestPersistentVolumeDescriber(t *testing.T) { block := corev1.PersistentVolumeBlock file := corev1.PersistentVolumeFilesystem <del> deletionTimestamp := metav1.Time{Time: time.Now().UTC().AddDate(10, 0, 0)} </del> <ins> deletionTimestamp := metav1.Time{Time: time.Now().UTC().AddDate(-10, 0, 0)} </ins> testCases := []struct { name               string plugin             string

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: Kubectl describe pv xxx shows last<invalidif pv is terminating ! I found pvc and pod have the same issue What you expected to happen: Terminating (lasts 10s) How to reproduce it (as minimally and precisely as possible): 1 create a pv, pvc or pod is terminating 2 using kubectk describe xxx Anything else we need to know?: Environment: Kubernetes version (use ): 1.13.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig cli
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
Change:
) nodeAuthorizer := node.NewAuthorizer(graph, nodeidentifier.NewDefaultNodeIdentifier(), bootstrappolicy.NodeRules()) authorizers = append(authorizers, nodeAuthorizer) <ins> ruleResolvers = append(ruleResolvers, nodeAuthorizer) </ins> case modes.ModeAlwaysAllow: alwaysAllowAuthorizer := authorizerfactory.NewAlwaysAllowAuthorizer()

Discussion:
What happened: I checked if kubelet () has permissions for with SelfsubjectAccessReviews and I saw that it has. But when I checked its permissions with SelfsubjectRulesReviews it didn't show it. What you expected to happen: I expected that the API SelfsubjectRulesReviews will show that has permssions for . How to reproduce it (as minimally and precisely as possible): You can check it on the master or the worker. Test SelfsubjectAccessReviews: You will get answer that it has permissions: Test SelfsubjectRulesReviews: It won't show the permissions. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ):Install tools: kubeadm /area/api /kind/bug /sig api-machinery
/sig api-machinery
This is a more clean display that show the bug: I think the problem is related to the fact that the file contain the kubelet certificate which is part of the group :
/sig auth
What is the SelfSubjectRulesReview response from the server ()? Note that not all authorizers support enumerating permissions, and the API object status includes an attribute which explicitly indicates the result is incomplete. See
It has Details:
I noticed that it also doesn't show that it has permissions to view and . It probably related to the Node authorizer: Because I assume that these rules doesn't appear in RBAC.
The node authorizer does not enumerate permissions, so it does not contribute to SelfSubjectRulesReview results
fixes setting correctly when the API is requested with a kubelet's credentials
Change:
} } sortObjects(wantObjects) <del> stripObjects(wantObjects) stripObjects(objects) </del> // Sometimes assert strips the diff too much, let's do it ourselves... <del> if diff := cmp.Diff(wantObjects, objects); diff != "" { </del> <ins> if diff := cmp.Diff(wantObjects, objects, cmpopts.IgnoreFields(metav1.ObjectMeta{}, "UID", "ResourceVersion")); diff != "" { </ins> t.Errorf("Stored objects are different (- expected, + actual):n%s", diff) }

Discussion:
pull-kubernetes-unit dynamicresources unknown multiple failures in tests as seen in n/a /sig scheduling
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
probably cc
/assign
DeepCopy missing here:
Change:
} }) <del> ginkgo.It("should locate the groupVersion and a resource within each APIGroup", func(ctx context.Context) { </del> <ins> /* Release: v1.28 Testname: Discovery, confirm the groupVerion and a resourcefrom each apiGroup Description: A resourceList MUST be found for each apiGroup that is retrieved. For each apiGroup the groupVersion MUST equal the groupVersion as reported by the schema. From each resourceList a valid resource MUST be found. */ framework.ConformanceIt("should locate the groupVersion and a resource within each APIGroup", func(ctx context.Context) { </ins> tests := []struct { apiBasePath   string

Discussion:
[X] test approval issue : [X] test pr : 3 May 2023 [X] two weeks soak end date : 16 May 2023 [X] test promotion pr : [X] remove endpoint form file According to following two APIsnoop queries, there are still 12 APIResources endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 12 endpoints. The e2e logs for this test are listed below. This query shows the following apiresources 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 12 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/open For tracking the rest of the processes
/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:
service to allow other pods to reach this mysql instance. The name is `wordpress-mysql` which resolves to the pod IP. <ins> Up to this point one Deployment, one Pod, one PVC, one Service, one Endpoint, two PVs, and one Secret have been created, shown below: ```shell kubectl get deployment,pod,svc,endpoints,pvc -l app=wordpress -o wide &&  kubectl get secret mysql-pass &&  kubectl get pv ``` ```shell NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE deploy/wordpress-mysql   1         1         1            1           3m NAME                                  READY     STATUS    RESTARTS   AGE       IP           NODE po/wordpress-mysql-3040864217-40soc   1/1       Running   0          3m        172.17.0.2   127.0.0.1 NAME                  CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE       SELECTOR svc/wordpress-mysql   None         <none>        3306/TCP   3m        app=wordpress,tier=mysql NAME                 ENDPOINTS         AGE ep/wordpress-mysql   172.17.0.2:3306   3m NAME                 STATUS    VOLUME       CAPACITY   ACCESSMODES   AGE pvc/mysql-pv-claim   Bound     local-pv-2   20Gi       RWO           3m NAME         TYPE      DATA      AGE mysql-pass   Opaque    1         3m NAME         CAPACITY   ACCESSMODES   STATUS      CLAIM                    REASON    AGE local-pv-1   20Gi       RWO           Available                                      3m local-pv-2   20Gi       RWO           Bound       default/mysql-pv-claim             3m ``` </ins> ## Deploy WordPress Next deploy WordPress using

Discussion:
Version: Running this example on RHEL 7.2 (assume same for centos), and using hostPath, I get a permissions error when the mysql container does a . If I set selinux to permissive on the host it works. If I manually run the container with it works. I was not able to get it to work when adding to the deployment. My fix was to locate the PVs in by changing the local- file, and doing . I this comment to local- If this issue is valid I will create a quick PR to doc this selinux solution.
See pr
Change:
DeleteMirrorPod(podFullName string, uid *types.UID) (bool, error) } <del> // nodeGetter is a subset a NodeLister, simplified for testing. </del> <ins> // nodeGetter is a subset of NodeLister, simplified for testing. </ins> type nodeGetter interface { // Get retrieves the Node for a given name. Get(name string) (*v1.Node, error)

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 --Consider the following log line: I expected the podUID to be printed rather than an address/pointer. Run a static pod on a non-standalone kubelet, watch logs for mirrorclient entries. Fix is this line: We probably want to check if the UID is nil, and if so, print what it points to. /sig node /area logging /help Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This 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 : <!-- 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: /area logging /help 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: </details
/assign
/triage accepted
Change:
func waitForNextConfigMapEvent(watch watch.Interface) *v1.ConfigMap { select { <del> case event := <-watch.ResultChan(): </del> <ins> case event, ok := <-watch.ResultChan(): if !ok { framework.Failf("Watch closed unexpectedly") } </ins> if configMap, ok := event.Object.(*v1.ConfigMap); ok { return configMap } <del> framework.Failf("expected config map") </del> <ins> framework.Failf("expected config map, got %T", event.Object) </ins> case <-time.After(10 * time.Second): framework.Failf("timed out waiting for watch event") }

Discussion:
By inspection, the "should receive events on concurrent watches in same order" conformance test does two things that are not stable: Starts watches from resourceVersion=0 Relies on watch connections without handling timeouts/restarts This test can fail on clusters that have configmaps autocreated in namespaces already because ordering of watch events for resourceVersion=0 watches is undefined (see ) Watch connections used by conformance tests should use well-defined ordering (starting from resourceVersions other than 0) and handle interruptions properly. 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:
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
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