jiebi/CodeConvo huggingface dataset:
Change:
e2epod.DeletePodWithWait(f.ClientSet, pod) }() <del> err := e2epod.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) framework.ExpectError(err, "while waiting for pod to be running") </del> <ins> err := e2epod.WaitForPodContainerToFail(f.ClientSet, pod.Namespace, pod.Name, 0, "CreateContainerConfigError", framework.PodStartShortTimeout) framework.ExpectNoError(err, "while waiting for the pod container to fail") </ins> } func newPod(command []string, envVars []v1.EnvVar, mounts []v1.VolumeMount, volumes []v1.Volume) *v1.Pod {

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: N/A Which test(s) are failing: should fail substituting values in a volume subpath with absolute path Since when has it been failing: N/A Testgrid link: N/A Reason for failure: Some of the tests are negative test cases which are supposed to ensure that those invalid usecases are handled properly. However, some of the tests are false positives, they can pass due to various reasons. One such example is: should fail substituting values in a volume subpath with absolute path. This test can pass if: the Pod cannot start due to various reasons (e.g.: the container image cannot be pulled or does not exist). the Pod ran to completion, even though the container was not supposed to start in the first place. Anything else we need to know: /sig testing Related:
/sig storage SIG storage owns the test case, though I see that you are changing core framework methods to fix this, so leaving SIG testing. Looks like also possibly sig-node, skimming the linked PRs Based on the PRs this also appears to be related to windows? (unsure, no mention here)
I've Related: to the issue description. After fixing this test, I've noticed that it now fails on Windows, which means the issue was masked by the test's false positive result. Basically, it means that you can have volume subpaths with absolute paths substituted on variable expansion and have Windows containers use them and be running, which according to the test, it shouldn't be a supported usecase. The fix should probably be also backported to previous releases.
Change:
le.config.Lock.RecordEvent("stopped leading") glog.Infof("failed to renew lease %v: %v", desc, err) cancel() <del> }, 0, ctx.Done()) </del> <ins> }, le.config.RetryPeriod, ctx.Done()) </ins> } // tryAcquireOrRenew tries to acquire a leader lease if it is not already acquired,

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: After merged, the leader election is calling too many api calls. Previously it calls with a 2s interval by default. Now it calls with 0 interval. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig api-machinery
/assign
/kind bug
Change:
return nil } <del> switch mode := info.Mode(); { case mode.IsDir(): </del> <ins> mode := info.Mode() if mode.IsDir() { </ins> if err := w.fsWatcher.Add(path); err != nil { return fmt.Errorf("failed to watch %s, err: %v", path, err) } <del> case mode&os.ModeSocket != 0: </del> <ins> } else if isSocket, _ := util.IsUnixDomainSocket(path); isSocket { </ins> event := fsnotify.Event{ Name: path, Op:   fsnotify.Create,

Discussion:
Looking at [1], we can see that the plugin Watcher is traversing the plugin directory, and check whether a new file is a unix socket or not. However, : Those file should not have been ignored. Instead of using, which also has a Windows implementation [2]. This issue may also cause the unit tests to flake [3]. [1] [2] [3] Instead of using, which also has a Windows implementation [2]. This will result in the plugin Watcher to work as intended. Run the ` unit test. No response Kubernetes v1.25, v1.24. N/A Windows Server 2019 or newer. <details</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 windows /sig testing /milestone v1.25 /priority important-soon
/assign
Change:
}) /* <del> Release: v1.17 </del> <ins> Release: v1.17, v1.21 </ins> Testname: aggregator-supports-the-sample-apiserver Description: Ensure that the sample-apiserver code from 1.17 and compiled against 1.17 will work on the current Aggregator/API-Server.

Discussion:
[x] test pr : kuberenetes/kubernetes# [x] two weeks soak start date : testgrid-link [x] two weeks soak end date : [x] test promotion pr : kubernetes/kubernetes#? According to this APIsnoop query, there are still some remaining APIService 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 Addressing the following endpoints in this document; Using the current e2e test as a template, create an APIService for Using the REST client, read the APIService status (readApiregistrationV1APIServiceStatus) and confirm the value of . Using the REST client, patch the APIService (patchApiregistrationV1APIService) before confirming that it has been updated. Using the REST client, list all APIServices in the cluster (listApiregistrationV1APIService) before confirming that can be found. Clean up APIService resources used by the test. Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. This query shows the endpoints hit within a short period of running the e2e test example endpoint | useragent ---------------------------------------|
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator2 (6 rows) Based on the initial APIsnoop query and the results listed above there are three new endpoints hit.

If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Change:
package metrics import ( <del> "os" </del> "time" <del> "github.com/prometheus/procfs" </del> "k8s.io/klog/v2" )

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: Start kubelet on a Windows node and you will get this error: What you expected to happen: The process start time to be read appropriately for Windows How to reproduce it (as minimally and precisely as possible): Start kubelet on a Windows node Anything else we need to know?: The gauge falls back to but we get this error. This information is avaliable via the windows package so we should be able to get an accurate time. Environment: Kubernetes version (use ): 1.20.1 Cloud provider or hardware configuration: azure OS (e.g: ): Windows 2019 Kernel (e.g. ): Version 10.0..1637 Install tools: aks-engine (but would be any) Network plugin and version (if this is a network-related bug): Others: /sig windows /assign
/triage accepted
Change:
// decodeDockerConfigFieldAuth deserializes the "auth" field from dockercfg into a // username and a password. The format of the auth field is base64(<username>:<password>). func decodeDockerConfigFieldAuth(field string) (username, password string, err error) { <del> decoded, err := base64.StdEncoding.DecodeString(field) </del> <ins> var decoded []byte // StdEncoding can only decode padded string // RawStdEncoding can only decode unpadded string // a string is correctly padded if and only if its length is a multiple of 4 if (len(field) % 4) == 0 { // decode padded data decoded, err = base64.StdEncoding.DecodeString(field) } else { // decode unpadded data decoded, err = base64.RawStdEncoding.DecodeString(field) } </ins> if err != nil { return }

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:
], importpath = "k8s.io/kubernetes/test/integration/util", deps = [ <ins> "//pkg/api/legacyscheme:go_default_library", </ins> "//pkg/cloudprovider/providers/gce:go_default_library", "//pkg/scheduler:go_default_library", "//pkg/scheduler/api:go_default_library",

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: I0116 21:50:32. 3959 ] GET /healthz: (1.0472ms) 500 goroutine 2352 [running]: (respLogger).recordStatus(0xc001fa7110, 0x1f4) +0xd2 (respLogger).WriteHeader(0xc001fa7110, 0x1f4) +0x35 (baseTimeoutWriter).WriteHeader(0xc00382ad80, 0x1f4) +0xaf net/http.Error(0xdc0d5b8, 0xc0036a21c0, 0xc0003b5a40, 0x136, 0x1f4) +0xda (0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x3aa net/http.HandlerFunc.ServeHTTP(0xc0027a40e0, 0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x44 (pathHandler).ServeHTTP(0xc00278a900, 0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x510 (PathRecorderMux).ServeHTTP(0xc00014f340, 0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x8a (0x4c243b1, 0xe, 0xc0008aa360, 0xc00014f340, 0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x661 (0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x4c3 net/http.HandlerFunc.ServeHTTP(0xc0000da080, 0xdc0d5b8,

0xc0036a21c0, 0xc00380ef00) +0x44 (0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x459 net/http.HandlerFunc.ServeHTTP(0xc00071c9c0, 0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x44 (0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x1eeb net/http.HandlerFunc.ServeHTTP(0xc0000da700, 0xdc0d5b8, 0xc0036a21c0, 0xc00380ef00) +0x44 (0xdc0d5b8, 0xc0036a21c0, 0xc00380ee00) +0x476 net/http.HandlerFunc.ServeHTTP(0xc0008a9400, 0xdc0d5b8, 0xc0036a21c0, 0xc00380ee00) +0x44 (timeoutHandler).ServeHTTP.func1(0xc003637560, 0xc00045dd00, 0x6b6d240, 0xc0036a21c0, 0xc00380ee00) +0xb3 created by (timeoutHandler).ServeHTTP +0x1b0 panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x25f7a93] goroutine 3306 [running]: (Scheduler).bind(0xc00002db60, 0xc004ae3c00, 0xc0049d0a80, 0x0, 0x1c4efe1) +0x643 (Scheduler).scheduleOne.func1(0xc001ffe701, 0xc00002db60, 0xc004ae3c00, 0x6b51d40, 0xc003a1c1c0, 0xc001ffe700, 0x11, 0x64, 0x64,

0xbf07eb8a4781e3e8, .) +0x21f created by (Scheduler).scheduleOne +0xb6f exit status 2 FAIL 4.409s !!! Error in ./test- Error in ./test- 'go test - -test.timeout=60m -' exited with status 1 Call stack: 1: ./test- main(...) Exiting with status 1 Anything else we need to know: run shell
/sig testing /sig scheduling
/assign
Change:
const ( bridgenf                    = "/proc/sys/net/bridge/bridge-nf-call-iptables" <ins> bridgenf6                   = "/proc/sys/net/bridge/bridge-nf-call-ip6tables" </ins> externalEtcdRequestTimeout  = time.Duration(10 * time.Second) externalEtcdRequestRetries  = 3 externalEtcdRequestInterval = time.Duration(5 * time.Second)

Discussion:
BUG REPORT /kind bug What happened: Kubeadm checks that bridge-nf-call-iptables (IPv4) is set, but does not check for bridge-nf-call-ip6tables (IPv6) What you expected to happen: If IPv6 is being used, then Kubeadm should check for bridge-nf-call-ip6tables How to reproduce it (as minimally and precisely as possible): Just running Kubeadm, however it's only a problem when running IPv6 Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area ipv6 /area kubeadm
/sig network
Change:
linux/s390x linux/ppc64le darwin/amd64 <ins> darwin/arm64 </ins> windows/amd64 )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When trying to build kubectl from tip () on a M1 Macbook: Why is this needed: M1 MacBooks are a new major client platform that many developers will use. brew listed kubectl (kubernetes-cli) is one of the major packages still not supported on M1 () Since it's supported by go, it's only required to add it to the supported client list Locally I managed to add support using the following patch:
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 cli architecture
/sig release
Any updates on this? cheers
you can watch the PR:
it works, nice!!!
Done!!!
Change:
specs := []*spec.Swagger{} for _, v := range crd.Spec.Versions { <del> s, err := builder.BuildSwagger(crd, v.Name, builder.Options{V2: false, StripDefaults: true, StripValueValidation: true, AllowNonStructural: true}) </del> <ins> s, err := builder.BuildSwagger(crd, v.Name, builder.Options{V2: false, StripDefaults: true, StripValueValidation: true, StripNullable: true, AllowNonStructural: true}) </ins> if err != nil { return nil, err }

Discussion:
With in a CRD we get: This is because gnostic's OpenAPI proto types have no nullable support. Luckily CRDs keep working because in the upper error case we don't stop serving, just set the SSA schema to nil.
Thanks for reporting!
I think it should be "This is because gnostic's OpenAPI v2 proto types have no nullable support.". The problem is that we're not supposed to pass-in v3.
Source:
OK, We'll write a test and fix this, thanks Stefan!
/reopen This still happens in slightly different shape: This comes from :
That's a fairly different bug but yes, thanks!
Is this related to the stating that use of "anyOf" wouldn't be allowed after 1.16? We're seeing issue on OpenFaaS after going to 1.17.5 and 1.18. Usually upgrading K8s versions hasn't caused breaking changes and we're trying to figure out where to start with this one.
No. That post was about structural schemas. v1 CRDs are limited to structural schemas. v1beta1 CRDs can continue to create non-structural schemas until v1beta1 is no longer served (in 1.22) Also, is not completely disallowed, specific restrictions inside an clause (like ) are what are not allowed ("logical constraints using oneOf, allOf, anyOf, not are allowed").
extracted the newly found issue to to track separately with isolated reproducer /close
Closing this issue. <detailsIn response to : extracted the newly found issue to to track separately 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:
} fakeDocker.containerList = []docker.APIContainers{ { <del> // format is <container-id>--<manifest-id> Names: []string{"bar--foo"}, </del> <ins> // format is k8s--<container-id>--<manifest-id> Names: []string{"/k8s--bar--foo"}, </ins> ID:    "1234", }, { // network container <del> Names: []string{"k8snet--foo--"}, </del> <ins> Names: []string{"/k8s--net--foo--"}, </ins> ID:    "9876", }, }

Discussion:
release-master-blocking Conformance-GCE-master-kubetest2Kubernetes e2e suite.[It] [sig-network] Services should be able to change the type from ExternalName to ClusterIP [Conformance] ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test 07-11 15:51 EEST No response /sig cloud-provider 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
I remember some timeout has changed with ginkgo2 and something moved from 24hours to 1 hours, or something like that, is it possible that this is the problem here, in this job?
The Grinko timeout change could also be the root problem with this job:
hmm, we have to revisit the flags
hmm, this seems correct
that was a good observations, seems that job is failing because gathering the logs takes too much time !
there is no timeout set in the kubetest2 command here (not sure if this would be the place to set a timeout)
it seems kubetest has to be migrated to ginkgov2 it should use this as basis I'm on vacation this week, can somebody take over and open the issue and patch kubetest2?
looks like this file needs to get updated: add line 72:
oh, you already commented this :D
I will have a look later
Related: umbrella issue:
last testgrid run passed :)
Change:
"", // Default fsType ), Capabilities: map[testsuites.Capability]bool{ <del> testsuites.CapExec: true, </del> <ins> testsuites.CapExec:             true, testsuites.CapSingleNodeVolume: true, </ins> }, }, }

Discussion:
What happened: When we run csi hostpath driver e2e tests on a multi-node cluster some tests failed because they assume that volumes are node independent but this is not the case for some drivers like hostpath. Related PR; What you expected to happen: Skip the tests that assume volumes are node independent for the drivers that don't support node independent volumes. /sig storage /assign
Change:
srcs = [ ":package-srcs", "//cmd/kubeadm/app:all-srcs", <del> "//cmd/kubeadm/test:all-srcs", </del> <ins> "//cmd/kubeadm/test/cmd:all-srcs", </ins> ], tags = ["automanaged"], )

Discussion:
go test ./cmd/kubeadm/... fails with: it appears to be following a "RunCmd" pattern used by e2e tests, but unit tests should not require built binaries
can work on this
has a long discussion as to why this is. These tests only get run when gets run, which will produce the needed binary and pass it in as arg. For more information, authored this and should be able to provide more details.
Yup, the target explicitly ignores these tests: and like said, runs this script as part of its target:
then the test should have build tags to exclude it from a regular run of the package
or up for fixing that?
I thought build tags only works on the OS level or if you it would ignore it completely? Wouldnt break the command as well?
I'd also tolerate skipping the test if the built binary doesn't exist
I think that is a great solution. I think in I had initially suggested something like that. If everyone is ok with that, I will go ahead and make that change.
Sounds good, make that change and we'll see how it turns out. I'd really want these tests start working, so +1
Change:
fi } <del> # Verify and find the various tar files that we are going to use on the server. # # Vars set: #   SERVER_BINARY_TAR #   SALT_TAR function find-release-tars { SERVER_BINARY_TAR="${KUBE_ROOT}/server/kubernetes-server-linux-amd64.tar.gz" if [[ ! -f "$SERVER_BINARY_TAR" ]]; then SERVER_BINARY_TAR="${KUBE_ROOT}/_output/release-tars/kubernetes-server-linux-amd64.tar.gz" fi if [[ ! -f "$SERVER_BINARY_TAR" ]]; then echo "!!! Cannot find kubernetes-server-linux-amd64.tar.gz" exit 1 fi SALT_TAR="${KUBE_ROOT}/server/kubernetes-salt.tar.gz" if [[ ! -f "$SALT_TAR" ]]; then SALT_TAR="${KUBE_ROOT}/_output/release-tars/kubernetes-salt.tar.gz" fi if [[ ! -f "$SALT_TAR" ]]; then echo "!!! Cannot find kubernetes-salt.tar.gz" exit 1 fi } </del> # Take the local tar files and upload them to the master. # # Assumed vars:

Discussion:
I suspect we're going through an if/else clause where KUBETARURL isn't defined, and not defaulting it, though the function header seems to indicate it should be set in the callee.
Will take a look.
Is this in Jenkins, or on a local run? The Jenkins push job is borked as well, but it looks like it's for a different reason: Which I'm taking care of in .
Jobs are generating incredibly large log files (300 Megs?) with lots of repeated lines like this: Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 I think this needs to be resolved, since it already caused an out-of-disk in Jenkins.
Okiedokie. Yes, this was my fault. silently expects and to be set in . I the extra expectation that be set, but didn't think about how would then also have to set that. Working on a fix.
(For anyone who cares, culprit is .)
Change:
} cap := persistentSpec.Spec.Capacity[v1.ResourceStorage] size := cap.Value() <del> if size != 100*1024*1024*1024 { </del> <ins> if size != 100*volume.GB { </ins> t.Errorf("Provision() returned unexpected volume size: %v", size) }

Discussion:
GCE PDs are allocated in chunks of GBs (not GiB) but function incorrectly creates volume in chunks of GiB - cc /sig storage
/kind bug
/assign
/priority important-soon
Hey I submit a pr for this issue. Your suggestions are very important. Thanks.