jiebi/CodeConvo huggingface dataset:
Change:
// Set up an API server controlPlaneConfig := framework.NewIntegrationTestControlPlaneConfig() <del> controlPlaneConfig.GenericConfig.Authentication.Authenticator = authenticator </del> <ins> controlPlaneConfig.GenericConfig.Authentication.Authenticator = group.NewAuthenticatedGroupAdder(authenticator) </ins> controlPlaneConfig.GenericConfig.Authorization.Authorizer = allowAliceAuthorizer{} _, s, closeFn := framework.RunAnAPIServer(controlPlaneConfig) defer closeFn()

Discussion:
While moving APF to beta (see comments on ), we discovered that the integration tests commonly present users which are not members of any groups. We had thought that the system enforced membership in either the authenticated or unauthenticated group. If this is supposed to be a system invariant (as we thought), we'd like to ask SIG Auth: Please fix the integration tests Please add e.g. logging so that if real, operational clusters hit this there's at least a log message and people will file bugs. /sig auth
Can I suggest also, if this is a real invariant, that it be documented in some place(s) likely to be read?
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /priority important-longterm /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen
fixes the authenticator configured in one of the integration test API server startup helpers which resolved this issue for . Remaining tests that still need fixing that are encountering unexpected users look to be ones set up to specifically test auth paths:
open to fix remaining integration test users
Change:
ginkgo := filepath.Join(outputDir, "ginkgo") test := filepath.Join(outputDir, "e2e_node.test") <del> if *systemSpecName == "" { runCommand(ginkgo, *ginkgoFlags, test, "--", *testFlags) return </del> <ins> args := []string{*ginkgoFlags, test, "--", *testFlags} if *systemSpecName != "" { rootDir, err := builder.GetK8sRootDir() if err != nil { glog.Fatalf("Failed to get k8s root directory: %v", err) } systemSpecFile := filepath.Join(rootDir, systemSpecPath, *systemSpecName+".yaml") args = append(args, fmt.Sprintf("--system-spec-name=%s --system-spec-file=%s", *systemSpecName, systemSpecFile)) </ins> } <del> rootDir, err := builder.GetK8sRootDir() if err != nil { glog.Fatalf("Failed to get k8s root directory: %v", err) </del> <ins> if err := runCommand(ginkgo, args...); err != nil { glog.Exitf("Test failed: %v", err) </ins> } <del> systemSpecFile := filepath.Join(rootDir, systemSpecPath, *systemSpecName+".yaml") runCommand(ginkgo, *ginkgoFlags, test, "--", fmt.Sprintf("--system-spec-name=%s --system-spec-file=%s", *systemSpecName, systemSpecFile), *testFlags) </del> return }

Discussion:
Currently, always returns with 0 exit code no matter the test fails or not. We should fix it to return non-zero exit code for test failure.
Change:
httplog.StatusIsNot( http.StatusOK, http.StatusAccepted, <ins> http.StatusMovedPermanently, </ins> http.StatusTemporaryRedirect, http.StatusConflict, http.StatusNotFound, <ins> StatusUnprocessableEntity, </ins> ), ).Log()

Discussion:
I0825 04:43:42. ] GET /logs: (51.111us) 301 goroutine 315 [running]: (respLogger).WriteHeader(0xc21036a240, 0x12d) +0x9c net/http.Redirect(0x7f4d60b7ed80, 0xc21036a240, 0xc2101a7680, 0xc2102bbd60, 0x6, ...) +0x436 net/http.(redirectHandler).ServeHTTP(0xc2103089c0, 0x7f4d60b7ed80, 0xc21036a240, 0xc2101a7680) +0x5e net/http.(ServeMux).ServeHTTP(0xc2102f4030, 0x7f4d60b7ed80, 0xc21036a240, 0xc2101a7680) +0x163 ·002(0x7f4d60b7ed48, 0xc2102c5140, 0xc2101a7680) +0x197 net/http.HandlerFunc.ServeHTTP(0xc210309180, 0x7f4d60b7ed48, 0xc2102c5140, 0xc2101a7680) +0x40 (defaultAPIServer).ServeHTTP(0xc210308a60, 0x7f4d60b7ed48, 0xc2102c5140, 0xc2101a7680) +0x51 net/http.serverHandler.ServeHTTP(0xc210317960, 0x7f4d60b7ed48, 0xc2102c5140, 0xc2101a7680) +0x16e net/http.(conn).serve(0xc2102b2180) +0x7b7 created by net/http.(Server).Serve +0x28b
Is it just that 301 isn't in the list of things to not show a stacktrace for?
Change:
endpointsHandler.ValidateRequestCount(t, 0) } <ins> func TestSyncEndpointsExistingNilSubsets(t *testing.T) { ns := metav1.NamespaceDefault testServer, endpointsHandler := makeTestServer(t, ns) defer testServer.Close() endpoints := newController(testServer.URL) endpoints.endpointsStore.Add(&v1.Endpoints{ ObjectMeta: metav1.ObjectMeta{ Name:            "foo", Namespace:       ns, ResourceVersion: "1", }, Subsets: nil, }) endpoints.serviceStore.Add(&v1.Service{ ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: ns}, Spec: v1.ServiceSpec{ Selector: map[string]string{"foo": "bar"}, Ports:    []v1.ServicePort{{Port: 80}}, }, }) endpoints.syncService(ns + "/foo") endpointsHandler.ValidateRequestCount(t, 0) } func TestSyncEndpointsExistingEmptySubsets(t *testing.T) { ns := metav1.NamespaceDefault testServer, endpointsHandler := makeTestServer(t, ns) defer testServer.Close() endpoints := newController(testServer.URL) endpoints.endpointsStore.Add(&v1.Endpoints{ ObjectMeta: metav1.ObjectMeta{ Name:            "foo", Namespace:       ns, ResourceVersion: "1", }, Subsets: []v1.EndpointSubset{}, }) endpoints.serviceStore.Add(&v1.Service{ ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: ns}, Spec: v1.ServiceSpec{ Selector: map[string]string{"foo": "bar"}, Ports:    []v1.ServicePort{{Port: 80}}, }, }) endpoints.syncService(ns + "/foo") endpointsHandler.ValidateRequestCount(t, 0) } func TestSyncEndpointsNewNoSubsets(t *testing.T) { ns := metav1.NamespaceDefault testServer, endpointsHandler := makeTestServer(t, ns) defer testServer.Close() endpoints := newController(testServer.URL) endpoints.serviceStore.Add(&v1.Service{ ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: ns}, Spec: v1.ServiceSpec{ Selector: map[string]string{"foo": "bar"}, Ports:    []v1.ServicePort{{Port: 80}}, }, }) endpoints.syncService(ns + "/foo") endpointsHandler.ValidateRequestCount(t, 1) } </ins> func TestCheckLeftoverEndpoints(t *testing.T) { ns := metav1.NamespaceDefault testServer, _ := makeTestServer(t, ns)

Discussion:
Currently, endpoints objects containing no subsets are decoded by the go client as subsets:[] (when requested individually) or as subsets:null (when requested in a list of endpoints). Because the endpoints controller is fed via a lister/watcher, it gets the subsets:null version fed to it. The subsets computation then returns an empty slice, which fails reflect.DeepEqual, which triggers a write attempt
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Change:
local times=${5:-30} local maxtime=${6:-1} <del> kube::util::wait_for_url "${url}" "${prefix}" "${wait}" "${times}" "${maxtime}" "--oauth2-bearer ${token}" </del> <ins> kube::util::wait_for_url "${url}" "${prefix}" "${wait}" "${times}" "${maxtime}" -H "Authorization: Bearer ${token}" </ins> } # Example:  kube::util::wait_for_success 120 5 "kubectl get nodes|grep localhost"

Discussion:
What happened: After running ./hack/update-openapi- with the latest code, api/openapi- file became empty even when no changes were made in the code. What you expected to happen: After running ./hack/update-openapi- with the latest code, api/openapi- file should not be changed when no changes were made in the code. When I tried the same thing a few week back, I didn't encounter this problem. How to reproduce it (as minimally and precisely as possible): Download the latest kubernetes/kubernetes code and run the following script to update openapi spec. api/openapi- became empty after this. Anything else we need to know?: There's a line in update-openapi- that runs a curl command . This line was changed a few days ago by this commit: PR: I checked out the commit before and ran /update-openapi- It works. is not empty any more. Is there any new setting required before running ./hack/update-openapi- now? 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
cc
Hi, thanks for the report, but it is a bit weird that I could not reproduce locally: and besides, completes successfully on my machine. Could you reproduce?
Someone else also ran into this same problem and asked a question on sig-api-machinery slack yesterday. So I'm not the only one who ran into this.
could you change the args passed to curl in to and rerun the script to see if there is any error?
since it is already late here(UTC+8), I would check this issue again tomorrow
I was the "someone else" who ran into this problem :) I changed the script to use The result: Actually, it was 403 without the "S", too, but that is visible only if curl is executed in verbose mode.
Hi, thanks for your information. Given that the apiserver returned 403, I suspect the flag passed to curl has no effect in your environment, would you mind posting the output of ? I am using curl 7.64.1: In addition, I think you could try changing the curl command in to the following: and see if the problem is solved.

I tried the following and it worked for me. is no longer empty. curl version:
Thanks for your confirmation, and I have filed to address this issue.
I can confirm, it works with the changed curl command.
/triage accepted
Change:
return false, nil } <del> if countEndpointsSlicesNum(esList) != expectNum { Logf("Unexpected number of Endpoints on Slices, got %d, expected %d", countEndpointsSlicesNum(esList), expectNum) </del> <ins> if countEndpointsSlicesNum(esList, addressType) != expectNum { Logf("Unexpected number of Endpoints on Slices, got %d, expected %d", countEndpointsSlicesNum(esList, addressType), expectNum) </ins> return false, nil } return true, nil

Discussion:
All the dual stack jobs ! ,%20ipvs,%20dual,%20master All dual stacks tests Since I modified this helper function to fix a flake ,%20ipvs,%20dual,%20master The function must consider only one IP family to verify the number of endpoints /assign /sig network /sig testing
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
Change:
<del> /* Copyright 2016 The Kubernetes Authors. 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. */ package kubeadm import ( "flag" "os" "path/filepath" "regexp" "testing" ) const ( TokenExpectedRegex = "^S{6}:S{16}n$" ) var kubeadmPath string func init() { flag.StringVar(&kubeadmPath, "kubeadm-path", filepath.Join(os.Getenv("KUBE_ROOT"), "cluster/kubeadm.sh"), "Location of kubeadm") } func TestCmdTokenGenerate(t *testing.T) { stdout, _, err := RunCmd(kubeadmPath, "ex", "token", "generate") if err != nil { t.Fatalf("'kubeadm ex token generate' exited uncleanly: %v", err) } matched, err := regexp.MatchString(TokenExpectedRegex, stdout) if err != nil { t.Fatalf("encountered an error while trying to match 'kubeadm ex token generate' stdout: %v", err) } if !matched { t.Errorf("'kubeadm ex token generate' stdout did not match expected regex; wanted: [%q], got: [%s]", TokenExpectedRegex, stdout) } } func TestCmdTokenGenerateTypoError(t *testing.T) { /* Since we expect users to do things like this: $ TOKEN=$(kubeadm ex token generate) we want to make sure that if they have a typo in their command, we exit with a non-zero status code after showing the command's usage, so that the usage itself isn't captured as a token without the user noticing. */ _, _, err := RunCmd(kubeadmPath, "ex", "token", "genorate") // subtle typo if err == nil { t.Error("'kubeadm ex token genorate' (a deliberate typo) exited without an error when we expected non-zero exit status") } } </del>

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:
args:  []string{"pods=bar"}, errFn: func(err error) bool { return strings.Contains(err.Error(), "one or more resources must be specified") }, }, <ins> "resources but no selectors": { args: []string{"pods", "app=bar"}, errFn: func(err error) bool { return strings.Contains(err.Error(), "resource(s) were provided, but no name, label selector, or --all flag specified") }, }, "multiple resources but no selectors": { args: []string{"pods,deployments", "app=bar"}, errFn: func(err error) bool { return strings.Contains(err.Error(), "resource(s) were provided, but no name, label selector, or --all flag specified") }, }, </ins> } for k, testCase := range testCases {

Discussion:
When users try to label/annotate multiple resources, we should tell them to add . Current output: Expected output:
and too
Instead of "--all is false", say "multiple resources were provided, but no label selector or --all flag specified"
Description updated based on suggestion
I think "resource(s) were provided, but no name, label selector, or --all flag specified" is better. I will send a pull request for this as my first PR.
Change:
history := NewHistory(client, informer.Lister()) var collisionCount int32 <del> for i := range test.existing { _, err := history.CreateControllerRevision(test.existing[i].parent, test.existing[i].revision, &collisionCount) </del> <ins> for _, item := range test.existing { _, err := client.AppsV1().ControllerRevisions(item.parent.GetNamespace()).Create(item.revision) </ins> if err != nil { t.Fatal(err) }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT: What happened: When a statefulset object is created, a lot of controllerrevisions are created at the same time. the controllerrevisions have differenct hash value but the same Data.Raw. How to fix it: two controllerrevisions are seen as the same , when [ControllerRevisionHashLabel] , Controllerrevision.Data.Raw , Controllerrevision.Data.Object are strictly the same // this line shoud be to fix the bug like below: Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.8 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I would help fix it
/kind bug /sig apps
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
StatefulSet uses the following code to construct its history object (controllerrevision): However, collisionCount shouldn't be blindly increased when there's name collision. Because controller uses a cache store, the name collision could be due to a controllerrevision created but not yet observed by the controller. The right way to handle it is to first check if the controllerrevision with the same name has the same content as the one we're going to create, like how DaemonSet controller handles it:
Change:
return "", false, fmt.Errorf("deployment %q exceeded its progress deadline", name) } if deployment.Spec.Replicas != nil && deployment.Status.UpdatedReplicas < *deployment.Spec.Replicas { <del> return fmt.Sprintf("Waiting for rollout to finish: %d out of %d new replicas have been updated...n", deployment.Status.UpdatedReplicas, *deployment.Spec.Replicas), false, nil </del> <ins> return fmt.Sprintf("Waiting for deployment %q rollout to finish: %d out of %d new replicas have been updated...n", name, deployment.Status.UpdatedReplicas, *deployment.Spec.Replicas), false, nil </ins> } if deployment.Status.Replicas > deployment.Status.UpdatedReplicas { <del> return fmt.Sprintf("Waiting for rollout to finish: %d old replicas are pending termination...n", deployment.Status.Replicas-deployment.Status.UpdatedReplicas), false, nil </del> <ins> return fmt.Sprintf("Waiting for deployment %q rollout to finish: %d old replicas are pending termination...n", name, deployment.Status.Replicas-deployment.Status.UpdatedReplicas), false, nil </ins> } if deployment.Status.AvailableReplicas < deployment.Status.UpdatedReplicas { <del> return fmt.Sprintf("Waiting for rollout to finish: %d of %d updated replicas are available...n", deployment.Status.AvailableReplicas, deployment.Status.UpdatedReplicas), false, nil </del> <ins> return fmt.Sprintf("Waiting for deployment %q rollout to finish: %d of %d updated replicas are available...n", name, deployment.Status.AvailableReplicas, deployment.Status.UpdatedReplicas), false, nil </ins> } return fmt.Sprintf("deployment %q successfully rolled outn", name), true, nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: In our CI, we run multiple times in parallel when we update multiple deployments. This lets us see the status of all deployments as they run. When a deployment succeeds, the final message tells us the name of the deployment. However, the intermediate "Waiting for rollout to finish" messages do not say the name of the deployment. This means that in order to look at multiple rollouts in parallel, we need to manually pipe through another command to prefix it with the rollout name. What you expected to happen: Each line to mention the rollout name. How to reproduce it (as minimally and precisely as possible): Update any deployment, run , note that intermediate status names don't contain the deployment name. Anything else we need to know?: Arguably another fix would be to allow you to pass multiple rollouts to and have kubectl handle polling multiple deployments in parallel. Environment: This is still true on master by code inspection.
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
Change:
}) AfterEach(func() { <del> // Remove any remaining pods from this test DeleteRC(c, ns, RCName) </del> <ins> // Remove any remaining pods from this test if the // replication controller still exists and the replica count // isn't 0.  This means the controller wasn't cleaned up // during the test so clean it up here rc, err := c.ReplicationControllers(ns).Get(RCName) if err == nil && rc.Spec.Replicas != 0 { DeleteRC(c, ns, RCName) } </ins> }) It("should allow starting 100 pods per node", func() {

Discussion:
If the cleanup of the replication controller takes too long after a successful test run, then the clean up performed in the AfterEach can actually cause the test to fail. Should only perform the clean up if the rc exists and its replica count is non-zero.
Change:
}, } volume.TestVolumeClient(f, config, nil, "" /* fsType */, tests) <del> volume.TestCleanup(f, config) </del> } // installFlex installs the driver found at filePath on the node, and restarts

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in
Change:
Version: "v1beta1", }, }, <ins> Labels: validSelector, </ins> } successCases := []ReplicationController{

Discussion:
If a ReplicaController has a selector that doesn't match the template it'll just create tons and tons of pods. It should validate that the pods it is creating have a good chance of satisfying its selector.
It would also be useful to validate that the selector doesn't obviously overlap with selectors of other replicationControllers.