jiebi/CodeConvo huggingface dataset:
Change:
testReadFile(f, l.filePathInSubpath, l.pod, 0) }) <del> It("should verify container cannot write to subpath readonly volumes", func() { </del> <ins> It("should verify container cannot write to subpath readonly volumes [Slow]", func() { </ins> init() defer cleanup() if l.roVolSource == nil {

Discussion:
created a spread sheet of the slowest running tests for the pull-kubernetes-gce job. cc discussion on slack: spreadsheet: pie chart of test durations from SIGs: ! it seems appropriate to evaluate the state of the tests and reduce these runtimes. possibly move tests to periodic by marking them as [Slow]. /assign /kind design /area test (?)
/remove-kind bug
Are pull jobs the right place to be calculating the time? Or should be be counting in CI instead?
pull is the one timing out, so probably?
Looking at some of the top slowness:: subPath should fail for new directories when readOnly specified in the volumeSource: This test case is no longer defined in master HostPathType: This test case has not been checked in yet and is trying to be in a PR PersistentVolumes-local StatefulSet with pod affinity should use volumes spread across nodes when pod has anti-affinity: This test is already marked as slow in master
Created This should address most of the top slow storage tests
Change:
password: "bar", }, <ins> // some test as before but with field not well padded { input:    "Zm9vOmJhcg", username: "foo", password: "bar", }, // standard encoding (with padding) { input:    base64.StdEncoding.EncodeToString([]byte("foo:bar")), username: "foo", password: "bar", }, // raw encoding (without padding) { input:    base64.RawStdEncoding.EncodeToString([]byte("foo:bar")), username: "foo", password: "bar", }, // the input is encoded with encodeDockerConfigFieldAuth (standard encoding) { input:    encodeDockerConfigFieldAuth("foo", "bar"), username: "foo", password: "bar", }, </ins> // good base64 data, but no colon separating username & password { input: "cGFudHM=",

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: docker now provides a new favorite way to store the credentials with the variable credsStore in the file it it is set to desktop, which will be using the executable docker-credential-desktop whose source code is docker-credential-desktop doesn't pad the auth field. So, if we use the command k8s credential provider won't be able to decode the field because of the error Failed to pull image "myrepo/myimage:tag": illegal base64 data at input byte What you expected to happen: Image pulled normally How to reproduce it (as minimally and precisely as possible): open docker config file, and have credsStore set to desktop. Run docker login and then use the to create a k8s dockerconfigjson secret, the error will directly show Anything else we need to know?: I wrote a patch that I will submit Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-19T12:38:36Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64" Cloud provider or hardware configuration: minikube version: v1.3.1 commit: OS (e.g: ): Mac Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig Apps
/remove-sig apps /sig auth /sig node cc to triage
Change:
* all * certificatesigningrequests (aka 'csr') <del> * clusters (valid only for federation apiservers) </del> * clusterrolebindings * clusterroles <ins> * clusters (valid only for federation apiservers) </ins> * componentstatuses (aka 'cs') * configmaps (aka 'cm') <ins> * cronjobs </ins> * daemonsets (aka 'ds') * deployments (aka 'deploy') * endpoints (aka 'ep')

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 ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: It is losing in help info. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
will make a pr to address that
Change:
if kc.HealthzPort != 0 && utilvalidation.IsValidPortNum(int(kc.HealthzPort)) != nil { allErrors = append(allErrors, fmt.Errorf("invalid configuration: HealthzPort (--healthz-port) %v must be between 1 and 65535, inclusive", kc.HealthzPort)) } <ins> if !localFeatureGate.Enabled(features.CPUCFSQuotaPeriod) && kc.CPUCFSQuotaPeriod != defaultCFSQuota { allErrors = append(allErrors, fmt.Errorf("invalid configuration: CPUCFSQuotaPeriod %v requires feature gate CustomCPUCFSQuotaPeriod", kc.CPUCFSQuotaPeriod)) } </ins> if localFeatureGate.Enabled(features.CPUCFSQuotaPeriod) && utilvalidation.IsInRange(int(kc.CPUCFSQuotaPeriod.Duration), int(1*time.Microsecond), int(time.Second)) != nil { allErrors = append(allErrors, fmt.Errorf("invalid configuration: CPUCFSQuotaPeriod (--cpu-cfs-quota-period) %v must be between 1usec and 1sec, inclusive", kc.CPUCFSQuotaPeriod)) }

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 --See for more context. What happened: When you set and , you'd expect container cfs quota period to be . However, unless you also set in the feature flags, the quota value will be silently ignored. What you expected to happen: At least a warning be logged if the feature is not enabled but is set. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: 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:
/sig node /assign karan
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig node 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:
import ( "fmt" <ins> "time" </ins> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: https://k8s- https://k8s-
/assign /priority critical-urgent /kind failing-test cc
/cc this is the symptom you said had an internal fix coming by end of week (ie: today)?
No this is purely oss
cc
Change:
var map_RollingUpdateDeployment = map[string]string{ "":               "Spec to control the desired behavior of rolling update.", <del> "maxUnavailable": "The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (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 to 70% of desired pods 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 the total number of pods available at all times during the update is at least 70% of desired pods.", </del> <ins> "maxUnavailable": "The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (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 to 70% of desired pods 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 the total number of pods available at all times during the update is at least 70% of desired pods.", </ins> "maxSurge":       "The maximum number of pods that can be scheduled above the desired number of pods. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number is calculated from percentage by rounding up. By default, a value of 1 is used. Example: when this is set to 30%, the new RC can be scaled up immediately when the rolling update starts, such that the total number of old and new pods do not exceed 130% of desired pods. Once old pods have been killed, new RC can be scaled up further, ensuring that total number of pods running at any time during the update is atmost 130% of desired pods.", }

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:
if config.Timeout == 0 { config.Timeout = defaultTimeout } <ins> if config.Burst == 0 && config.QPS < 100 { // discovery is expected to be bursty, increase the default burst // to accommodate looking up resource info for many API groups. // matches burst set by ConfigFlags#ToDiscoveryClient(). // see https://issue.k8s.io/86149 config.Burst = 100 } </ins> codec := runtime.NoopEncoder{Decoder: scheme.Codecs.UniversalDecoder()} config.NegotiatedSerializer = serializer.NegotiatedSerializerWrapper(runtime.SerializerInfo{Serializer: codec}) if len(config.UserAgent) == 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! If the matter is security related, please disclose it privately via --What happened: With client-go v0.17.0, I observed many "Throttling request" when DiscoveryClient is used to get API group resources from API server. This didn't happen with client-go kubernetes-1.16.0. It looks like originally this kind of discovery requests are not throttled because no rate limiter provided and QPS == 0. But with rate limiter is always set if nil rate limiter is provided. is particularly suspicious because it is always true because DefaultQPS is nonzero. What you expected to happen: Discovery requests should not be throttled as before. How to reproduce it (as minimally and precisely as possible): Create DiscoveryClient and then call with it. Anything else we need to know?: Environment: 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:
/sig api-machinery
The NewTokenBucketRateLimiter was via Always negotiate a decoder using ClientNegotiator /cc
To be clear, that was fixing a bug where the documented defaults for rate limiting were not taking effect. I don't think we should completely disable throttling until more of the server-side priority work is completed, but discovery is expected to be bursty, so I could see defaulting to a different amount in the discovery client constructor, similar to
Yeah, everyone must be rate limited. I think we could give discovery a big burst value.
opened
Change:
Long:    create_long, Example: create_example, Run: func(cmd *cobra.Command, args []string) { <del> err := RunCreate(f, out, cmd, filenames) cmdutil.CheckErr(err) </del> <ins> cmdutil.CheckErr(ValidateArgs(cmd, args)) cmdutil.CheckErr(RunCreate(f, out, cmd, filenames)) </ins> }, } cmd.Flags().VarP(&filenames, "filename", "f", "Filename, directory, or URL to file to use to create the resource") return cmd } <ins> func ValidateArgs(cmd *cobra.Command, args []string) error { if len(args) != 0 { return cmdutil.UsageError(cmd, "Unexpected args: %v", args) } return nil } </ins> func RunCreate(f *Factory, out io.Writer, cmd *cobra.Command, filenames util.StringList) error { schema, err := f.Validator() if err != nil {

Discussion:
cc
When deleting/stopping using file, you don't specify resource (in this case 'pod'), as it's inferred from the file.
Thanks and sorry for confusion
Ok, but should not work as well.
Change:
Expect(err).NotTo(HaveOccurred()) pst := statefulSetTester{c: c} <del> pst.saturate(ps) </del> nn := framework.TestContext.CloudConfig.NumNodes nodeNames, err := framework.CheckNodesReady(f.ClientSet, framework.NodeReadyInitialTimeout, nn)

Discussion:
What happened: What you expected to happen: The statefulset should have scaled down to 0. Instead, even after 10 minutes: How to reproduce it (as minimally and precisely as possible): Run the e2e test on a gce cluster running the latest and greatest kubernetes. cc
if the petset has replicas=0 it's not going to do anything
When I a running petset, and set its scale to 0, that seems to work and delete the pets, and we should have a functioning scaler. Am I misunderstanding something? I'm using the same teardown process for the e2e test I linked in the issue as the other tests (), but it times out sometimes after network partition.
yeah is scale in the petset controller noticing deletion timestamp? because the test code you showed doesn't care
As I mentioned yesterday, it isn't even issuing a delete request even after 10 minutes, because the pods continue to be "running". I'll check the controller manager logs today. I suspect it might be the backoff in the rate limited work-queue.
Hmm, the AGE fields on your pets don't make sense if it isn't even issuing a delete?
In the output I pasted above, at the 7 minute mark, it created the new replacement pet-0, after the network partition was healed. Then tried to scale down the StatefulSet and waited 10 minutes for the pods to disappear.
I see a bunch of different failures modes on the bug: 3 08:58:44.475: Failed waiting for pods to enter running: timed out waiting for the condition Failed to scale statefulset to 0 in 10m0s. Remaining pods: [] 3 08:11:30.728: Unexpected error: <nilBasically 3 translates to We should clarify. 1 and 2 both have events like guessing the node controlelr shouldn't be setting timestamp?
Looking into the case 2: The controller manager log goes: So I guess even deletions are being blocked by the health/readiness.
Both issues appear to be due to the testsuite and the way we use the "initialized" annotation in tests. I'll send a PR to fix these shortly. Thanks
Change:
} return false, err } <del> job := *sharedJob </del> <ins> // make a copy so we don't mutate the shared cache job := *sharedJob.DeepCopy() </ins> // if job was finished previously, we don't want to redo the termination if IsJobFinished(&job) {

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-integration-master I can't seem to find a match for beyond that? Most likely related to as it was merged during that set of commits Example Spyglass link: /cc /sig apps /priority critical-urgent /milestone v1.21
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
/assign
FYI: the error message is a red herring and isn't the real reason why this test is failing. When the integration tests are run with instead of , the mutation detector is also started, which catches a bug in the job controller where we modify the shared cache. This root cause isn't present in the logs, but you can reproduce this bug with the following command: Then apply the job controller patch in and re-run the test, you'll see that the test passes. You'll also notice that passes with/without the bug fix patch when run with . cc
Test is back on green. Thanks !
Change:
cleanup() { echo "Cleaning up..." <del> kill "${APISERVER_PID}" kill "${CTLRMGR_PID}" kill "${KUBELET_PID}" kill "${PROXY_PID}" kill "${SCHEDULER_PID}" </del> <ins> sudo kill "${APISERVER_PID}" sudo kill "${CTLRMGR_PID}" sudo kill "${KUBELET_PID}" sudo kill "${PROXY_PID}" sudo kill "${SCHEDULER_PID}" </ins> kill "${ETCD_PID}" rm -rf "${ETCD_DIR}"

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)
Change:
v1 "k8s.io/api/core/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/runtime" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes"

Discussion:
I'm writing a scheduler plugin using the scheduler framework, and in my plugin I'd like to add a using the provided by the . Adding such a Indexer lead to a runtime crash like The reason for this is that I'm not sure the scheduler framework wants to explicitely disallow adding Indexers using the facilities. If this is the case, it should be more explicit somehow because the current behaviour is surprising. If the scheduler framework doesn't want to add this limitation, then adding indexers should not lead to runtime crashes add a new scheduler plugin trying to add indexers. Sample code (relevant minimal portions only) I'm not sure this is a real bug and not a deliberate decision; a research was inconcusive, and a (admittedly quick) search in the past issues was not fruitful either. The fix could be as trivial as <detailsconsole $ kubectl version Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-01-18T23:30:10Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.5+", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-05-10T16:30:48Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"} </detailsbut applies also on latest master (see above) <detailsany </details<detailsany </details<detailsnot relevant </details<details</details<details</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 scheduling
Change:
isReady, err := podRunningReady(p) expectNoError(err) <del> Expect(isReady).To(BeTrue()) </del> <ins> Expect(isReady).To(BeTrue(), "pod should be ready") </ins> <del> Expect(getRestartCount(p) == 0).To(BeTrue()) </del> <ins> restartCount := getRestartCount(p) Expect(restartCount == 0).To(BeTrue(), "pod should have a restart count of 0 but got %v", restartCount) </ins> }) It("with readiness probe that fails should never be ready and never restart", func() {

Discussion:
If the container_probe test runs on a node without the nginx image, it sometimes takes 90s to get the pod in running. Most of this time goes in pulling the image, so I'm assuming it's registry related hiccup. Using might make it more reliable. Example failure: Note the following event in the logs:
a) we should not be pulling from docker in our tests - too hit-or-miss b) we should replace nginx (132 MB) with (4.5 MB) whenever possible. , Prashanth B wrote:
Change:
return metav1.StatusReasonUnknown } <ins> func reasonAndCodeForError(err error) (metav1.StatusReason, int32) { if status := APIStatus(nil); errors.As(err, &status) { return status.Status().Reason, status.Status().Code } return metav1.StatusReasonUnknown, 0 } </ins> // ErrorReporter converts generic errors into runtime.Object errors without // requiring the caller to take a dependency on meta/v1 (where Status lives). // This prevents circular dependencies in core watch code.

Discussion:
Checked a method error using when the error was caused by a validating webhook that returns a 403 response. In this particular case, the error was generated from a validating webhook implemented with controller-runtime that returns controller-runtime's response. to return true. returned false Many (but not all) of the other family of functions in suffer the same kind of problem. I have changes ready to submit in a PR if we can get agreement that this is a problem and that it should be fixed in the functions that ought to check the of an erorr value that is or wraps an Kubernetes version (use ): 19.3 for the server
/sig api-machinery
are you going to send a PR for this? The issue description looks reasonable. /triage accepted
Thanks, PR is submitted.
/assign
Change:
// f must run inside an It or Context callback. f := framework.NewDefaultFramework("stress") <del> init := func() *stressTest { </del> <ins> init := func() { </ins> cs = f.ClientSet <del> l := &stressTest{} </del> <ins> l = &stressTest{} </ins> // Now do the more expensive test initialization. l.config, l.driverCleanup = driver.PrepareTest(f)

Discussion:
/sig storage What happened: When you interrupt the e2e storage stress test, namespaced objects are cleaned up, but non-namespaced objects like StorageClasses are not cleaned up. What you expected to happen: Non-namespaced objects like StorageClasses are cleaned up so long as the user doesn't interrupt a second time. How to reproduce it (as minimally and precisely as possible):
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