jiebi/CodeConvo huggingface dataset:
Change:
Properties: map[string]spec.Schema{ "maxUnavailable": { SchemaProps: spec.SchemaProps{ <del> Description: "The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of total pods at the start of update (ex: 10%). Absolute number is calculated from percentage by rounding up. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old RC can be scaled down by 30% immediately when the rolling update starts. Once new pods are ready, old RC can be scaled down further, followed by scaling up the new RC, ensuring that at least 70% of original number of pods are available at all times during the update.", </del> <ins> Description: "The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of total pods at the start of update (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old RC can be scaled down by 30% immediately when the rolling update starts. Once new pods are ready, old RC can be scaled down further, followed by scaling up the new RC, ensuring that at least 70% of original number of pods are available at all times during the update.", </ins> Ref:         spec.MustCreateRef("#/definitions/intstr.IntOrString"), }, },

Discussion:
API documentation says is rounded up, but it is actually rounded down: The code shows it is rounded down, not up: and
Yes, the documentation is obsolete. We changed maxUnavailable to round down so that we wouldn't accidentally infer 100% unavailability for non-100 percentages. For example, maxSurge=25% and maxUanavailable=25% with a Deployment of 1 replica meant that we could scale down 1 before thus leading in 100% maxUnavailable (implicit).
Change:
w: &webhook.GenericWebhook{ RestClient:     rc, InitialBackoff: initialBackoff, <ins> ShouldRetry:    retryOnError, </ins> }, name: fmt.Sprintf("dynamic_%s", PluginName), }

Discussion:
What would you like to be : The api server should retry sending audit events to configured webhook sinks regardless of the type of HTTP error code it might receive from the webhooks. Why is this needed: While some components may live with failed data transmissions, this is a particularly sensitive topic for the audit area. The API server audit mechanisms must ensure that no other reasonable option exists before dropping an audit event that may be the only trace of malicious behavior in the cluster. It seems that the current implementation may be improved further in this direction. Currently, when the API server is configured for non-blocking sending of audit events to a webhook audit sink backend, it will retry up to 5 times with exponential backoff, should there be an error in communicating with the webhook, as implemented . However, not all errors will trigger a retry. Some are considered transient and yield retry. Others simply stop the retry cycle. For example, it retries on receiving HTTP code , but not on receiving . The list of error codes that will yield a retry is actually quite small - three HTTP errors and one network error. Any other error will not trigger a retry and the audit events will be lost. The code comments explain that the retry will consider only recoverable failures, which may make sense in other cases, but as far as sending audit events to an audit backend webhook is concerned, it is not sufficient policy. A more robust approach would be to consider any error and give the backend service a chance to recover instead of relying on the error codes semantics and the webhook implementations interpretation of it. That is more inline with having the transmission of audit events as top priority. /sig auth /sig api-machinery
Change:
} isListFromCache := !shouldListFromStorage(query, &listOptions) <del> count, err := e.countGetterFn(key(requestInfo)) </del> <ins> numStored, err := e.countGetterFn(key(requestInfo)) </ins> switch { case err == ObjectCountStaleErr: // object count going stale is indicative of degradation, so we should

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:
for _, pod := range ns.Pods { framework.Logf("creating/updating pod %s/%s", ns.Name, pod.Name) <ins> // note that we defer the logic of pod (i.e. node selector) specifics to the model // which is aware of linux vs windows pods </ins> kubePod, err := k.createPod(pod.KubePod()) if err != nil { return err } <del> createdPods = append(createdPods, kubePod) </del> <ins> createdPods = append(createdPods, kubePod) </ins> _, err = k.createService(pod.Service()) if err != nil { return err

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Ive done preliminary testing with on calico powered clusters on some windows variants and found that the probing seems to work. Can we add wrapper to netpol suite so that we can run it on windows clusters ? Why is this needed: We need this because otherwise, CNIs such as EKS will give us This error is caused when, for example, pods that are landing on a windows node havent defined their target platform. Somehow i guess pods which are landing on linux nodes dont have this issue. Its also needed for the obvious reason that we probably want separate linux and windows test suites for policies, in general, even though we expect the logic to be identical (modulo hostports , which we dont currently test)
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 windows
/assign
grepping around, I can't figure out where those are supposed to go. Can you give me pointers?
(resolved in slack, matts digging into this)
ok, these are running now on eks, lots of failures. will dig
/assign
the netpol are not being applied for the ns: Instead of failing because should not be able to access , the connection succeeds.
Change:
"github.com/pkg/errors" authorizationv1beta1 "k8s.io/api/authorization/v1beta1" rbacv1beta1 "k8s.io/api/rbac/v1beta1" <del> apierrors "k8s.io/apimachinery/pkg/api/errors" </del> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/util/wait"

Discussion:
What would you like to be : The function in should check for GKE and allow a missing SubjectAccessReview endpoint. If we get a 404 on another provider an error should still be returned. GKE doesn't enable the SAR endpoint. Without this endpoint, we cannot determine if the policy engine has adjusted as expected. In this case, we currently wait one second and hope it's up to date without returning an error and that it has adjusted as expected. Why is this needed: A 404 on that endpoint is not expected behavior for any provider other than GKE so it doesn't make any sense to implicitly allow 404s and hope that everything is ok. If it is a special, allowable, condition for GKE we should make that explicit in the code. The problem with doing it now is that checking the provider requires access to the TestContext which forces us to import the entire package. This goes against the goal of At the same time, we don't want to cause every test/caller of this to have to (1) know that GKE acts differently in this situation and code that one special path. This may be the lesser of the evils though, but regardless of how it is accomplished, at some point, the code should be validating this flow. Open to other solutions to this; maybe a specific test to test this code path (in which case this helper can be assumed to not be responsible for it?) Not sure if that is considered sufficient as it creates an awkward coupling between a helper function's assumptions and the existence of particular test.
/sig testing /area test /area test-framework
I think that comment no longer applies, and we can just remove that GKE special case. IIRC, GKE didn't initially enable serving the group, but it does now.
OK; I will: confirm GKE handling paste link here for history Put up PR removing the special case entirely
Change:
acceptPodName := framework.CreateExecPodOrFail(cs, namespace, "execpod-accept", nil) dropPodName := framework.CreateExecPodOrFail(cs, namespace, "execpod-drop", nil) <del> accpetPod, err := cs.Core().Pods(namespace).Get(acceptPodName, metav1.GetOptions{}) </del> <ins> acceptPod, err := cs.Core().Pods(namespace).Get(acceptPodName, metav1.GetOptions{}) </ins> Expect(err).NotTo(HaveOccurred()) dropPod, err := cs.Core().Pods(namespace).Get(dropPodName, metav1.GetOptions{}) Expect(err).NotTo(HaveOccurred())

Discussion:
Sub-issue for For AWS ELB, when an ELB is first created, is made it is very normal that it takes 2 minutes to be created, but the DNS name is reported fairly quickly.
Change:
func addDebugFlags(cmd *cobra.Command, opt *DebugOptions) { cmd.Flags().BoolVar(&opt.ArgsOnly, "arguments-only", opt.ArgsOnly, i18n.T("If specified, everything after -- will be passed to the new container as Args instead of Command.")) <del> cmd.Flags().BoolVar(&opt.Attach, "attach", opt.Attach, i18n.T("If true, wait for the Pod to start running, and then attach to the Pod as if 'kubectl attach ...' were called.  Default false, unless '-i/--stdin' is set, in which case the default is true.")) </del> <ins> cmd.Flags().BoolVar(&opt.Attach, "attach", opt.Attach, i18n.T("If true, wait for the container to start running, and then attach as if 'kubectl attach ...' were called.  Default false, unless '-i/--stdin' is set, in which case the default is true.")) </ins> cmd.Flags().StringVarP(&opt.Container, "container", "c", opt.Container, i18n.T("Container name to use for debug container.")) cmd.Flags().StringVar(&opt.CopyTo, "copy-to", opt.CopyTo, i18n.T("Create a copy of the target Pod with this name.")) cmd.Flags().BoolVar(&opt.Replace, "replace", opt.Replace, i18n.T("When used with '--copy-to', delete the original Pod"))

Discussion:
This issue tracks implementing node debugging with privileged containers for , as described in the This feature allows administrators to start a privileged container on a node in host namespaces rather than having to SSH to the node. For example: /kind feature /sig cli
/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
Change:
tests := []struct { name                                string volumePaths                         []string <del> expectedVolumesNeedReportedInUse    []string </del> expectedVolumesNeedDevicePath       []string expectedVolumesFailedReconstruction []string verifyFunc                          func(rcInstance *reconciler, fakePlugin *volumetesting.FakeVolumePlugin) error

Discussion:
remove and was introduced in to fix This is to overcome the situation that volume is to DSW at first and then deleted before it is to ASW, which causes mounted volume neither in DSW nor ASW and won't execute unmount/detach: The reason the volume cannot be to ASW in time is , which is . However, there is another PR also solved the issue. What it did is to check whether ASW already has the volume before deleting it from DSW, this makes sure that volume can be detached/unmounted after it is deleted from DSW. I suggest that we can keep the second solution and remove related code to make the reconstruction process and reconcile loop cleaner?
/sig storage
cc
Should I proceed with this issue? Your guidance is appreciated.
I think we'd better wait for the feedback from
cc
Sorry for a late reply. This is how behind we are with reviews :-(. Reading Now that is on by default, it reconstructs volumes first and always puts them to ASW, it should never happen that a reconstructed volume is in DSW and not in ASW, right? So we can remove easily. I would not be so sure without , because the code is 5 years old and who knows all the implications. You could be right though, it may not be necessary there too.
/triage accepted
/assign
Change:
} func createNewRC(c clientset.Interface, ns string, name string) { <del> _, err := common.NewRCByName(c, ns, name, 1, nil) </del> <ins> _, err := common.NewRCByName(c, ns, name, 1, nil, nil) </ins> framework.ExpectNoError(err) }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes Since when has it been failing: These tests have been failing since 6/28 Failures coincide with the following changes: Testgrid link: Reason for failure: The failure messages look as follows: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes /cc /milestone v1.16 /priority critical-urgent /kind failing-test /cc
/sig cluster-lifecycle
For more context, the code for the failing tests is here The error for both comes through  - some Pod is not responding. It is failing to find pods prefixed with "my-hostname-add-node". Within the logs we can see this: So the Pods are stuck in a Pending state. The Pods are supposed to be created by a ReplicationController in , which itself uses this method from the e2e framework . However, after being in a Pending state (after the "failed to wait for pods responding: timed out waiting for the condition" error is registered), they do seem to reach a Ready state
/assign for triage.
I think agnhost needs to be passed , but did not do so in /assign sig-testing
GitHub didn't allow me to assign the following users: sig-testing. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : I think agnhost needs to be passed , but did not do so in Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Reopen to monitor job /reopen
Reopened this issue.

<detailsIn response to : Reopen to monitor job /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
Thank you for working on the PR to solve this. indeed solved the issue reported here. /close
Closing this issue. <detailsIn response to : Thank you for working on the PR to solve this. /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:
originalCount := len(nodes.Items) containerName := "mycontainer" nodeToDelete := &nodes.Items[0] <del> defer func() error { </del> <ins> defer func() { </ins> By("Cleaning up PD-RW test env") detachAndDeletePDs(diskName, []types.NodeName{host0Name}) nodeToDelete.ObjectMeta.SetResourceVersion("0")

Discussion:
Since 2 days ago, the test is becoming more and more flaky, and one of the examples is: https://k8s-
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
please triage this one. Currently I put it as the release blocker, and please feel free to remove that if you think it is not. Thanks!
The test deletes the node, and at the end, waits 5 minutes for the node to become ready, but it timed out. cc
The test logic hasn't changed after I last modified it, so the test deletes the node through gcloud, and the instance should be restarted automatically by GCE because it's part of an instance template. The likely possibility, as pointed out, is that another change made node discovery take longer, so extending the timeout would be enough. The very unlikely possibility is there's a problem discovering brand new instances.
Change:
<ins> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # WARNING! HORRIBLE HACK! We expect /outerhost to be mapped to # the enclosing /etc/host file so we can determine the name of # the host machine (super fragile). This is a temporary hack until # service IPs are done. OUTER_HOST=`tail -n 1 /outerhost | awk '{print $3}'` # Copy the Fluentd config file and patch it to refer to the # name of the host machine for ES_HOST. HACK! cp td-agent.conf /etc/td-agent sed -i -e "s/ES_HOST/${OUTER_HOST}/" /etc/td-agent/td-agent.conf /usr/sbin/td-agent </ins>

Discussion:
After PR , I did a bit experiments on kube-dns graceful termination and got some unintended result as below: I guess it is because the other container was terminated before . DNS query from clients failed because is the actual connection point. After a bit discussion with and two solutions for this are: another program wrap up the dnsmasq and capture the SIGTERM signal. out a way to modify the sig mask of process without touching the original codes.
Something I have been meaning to try: Put in Dockerfile Build and push image We should deliver SIGCONT rather than SIGTERM. I did a quick test and it seems to work. Otherwise trapping SIGTERM in the shell and ignoring it is well documented... , Zihong Zheng wrote:
Thanks, I will take a look and test these.
Change:
"//test/e2e/framework/node:go_default_library", "//test/e2e/framework/pod:go_default_library", "//test/e2e/framework/service:go_default_library", <ins> "//test/utils:go_default_library", </ins> "//test/utils/image:go_default_library", "//vendor/github.com/onsi/ginkgo:go_default_library", "//vendor/github.com/onsi/gomega:go_default_library",

Discussion:
We need test cases that cover running as Windows users in containers. Windows uses a different field WindowsContainerSecurityContext.runasusername () They should only run with the ginkgo focus set. This will replace the similar test cases on Linux: /kind test /sig windows
/good-first-issue
/assign
GitHub didn't allow me to assign the following users: michellemcone. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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 I can't assign this to Michelle yet, so I'll park it on myself for now. If it's not done in a few weeks and someone else wants to take it, drop a comment here.
/milestone v1.14
/remove good-first-issue It looks like this may not be ready for testing. has the first half of the feature implemented, but it's still incomplete.
/assign So, when the API for `? Although this come at a later date, since it would need to be implemented in kubelet first.
GitHub didn't allow me to assign the following users: bclau. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign </details
/good-first-issue remove
/clear milestone
/milestone clear /kind cleanup
/remove-good-first-issue
/milestone v1.16
Hello! I'm part of the bug triage team for the 1.16 release cycle and considering this issue is tagged for 1.16, but not updated for a long time, I'd like to check its status. The code freeze is starting on August 29th (about 1.5 weeks from now), which means that there should be a PR ready (and merged) until then. Do we still target this issue to be fixed for 1.16? If not please re-tag the issue to the planned milestone.
This issue is addressed by: This should be included in 1.16.
Change:
"api/v1.0", }, "/"), } <del> _, err := c.MachineInfo() if err != nil { return nil, err } </del> return c, nil }

Discussion:
release-master-informing capg-conformance-main-ci-artifacts Kubernetes e2e suite.BeforeSuite 05-25 06:37 IST Failure Error waiting for all pods to be running and ready: 3 / 13 pods in namespace kube-system are NOT in RUNNING and READY state in 10m0s No response /sig network /sig node cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove sig-network /remove sig-node /unassign This seems a deployment problem ... on calico to be precise first point of contact for initial triage should be the job/sig owners ... this job also seems to be failing for a long time /sig cluster-lifecycle sig-cluster-lifecycle-cluster-api-alerts
/remove-sig network /remove-sig node
cc
will take a look /assign
Check the Calico version, there was a similar report that was fixed bumping the version. As a side not, I'm seeing a lot of problems related to Lots of projects/test/code were assuming the secret was created and is causing a lot of noise in different CIs
Hey thanks for the PR! The test still shows in the - will it take some time for the changes you made in the PR to reflect?
hello! those are not failures, they are flakys :/ afaik
Hey folks, this test has now started failing again on the dashboard. Should we open a new issue for it or is it okay to track it here itself? !
checking that
the capg conformance failed but now have flakys only
Thanks a ton