jiebi/CodeConvo huggingface dataset:
Change:
We run sonobuoy tests on production running clusters whenever we upgrade our clusters. We observe that fails when we already have nginx-ingress controller running in the cluster. The newer versions of nginx-ingress controller comes up with a validating admission webhook that validates the ingress definitions. In this specific test, we are creating 3 ingress objects with the same path and the webhook do not permit to create them (the first one is created but the other two would fail) and then the job fails. The tests shouldn't fail and it requires we create ingress objects using different paths instead. Install nginx-ingress controller from Run e2e test. Test fails. No response =1.19 n/a n/a n/a n/a n/a
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 testing /area e2e-test-framework
This is a duplicate, see the comment author of the ingress nginx controller explaining why this is working as expected Edit check again, maybe is not a duplicate
Thanks for pointing this. It's infact the same issue. But the fix above should hopefully help since it would create those ingress objects with different paths and the validating webhook for ingress controller would permit creating objects in that case.
yeah sorry, just checked quickly from the mobile, I will take a look Thanks

Discussion:
}, Status: networkingv1.IngressStatus{LoadBalancer: v1.LoadBalancerStatus{}}, } <ins> ingress1 := ingTemplate.DeepCopy() ingress1.Spec.Rules[0].Host = "host1.bar.com" ingress2 := ingTemplate.DeepCopy() ingress2.Spec.Rules[0].Host = "host2.bar.com" ingress3 := ingTemplate.DeepCopy() ingress3.Spec.Rules[0].Host = "host3.bar.com" </ins> // Discovery ginkgo.By("getting /apis") {

// Ingress resource create/read/update/watch verbs ginkgo.By("creating") <del> _, err := ingClient.Create(context.TODO(), ingTemplate, metav1.CreateOptions{}) </del> <ins> _, err := ingClient.Create(context.TODO(), ingress1, metav1.CreateOptions{}) </ins> framework.ExpectNoError(err) <del> _, err = ingClient.Create(context.TODO(), ingTemplate, metav1.CreateOptions{}) </del> <ins> _, err = ingClient.Create(context.TODO(), ingress2, metav1.CreateOptions{}) </ins> framework.ExpectNoError(err) <del> createdIngress, err := ingClient.Create(context.TODO(), ingTemplate, metav1.CreateOptions{}) </del> <ins> createdIngress, err := ingClient.Create(context.TODO(), ingress3, metav1.CreateOptions{}) </ins> framework.ExpectNoError(err) ginkgo.By("getting")
Change:
TestRoundTripSocks5AndNewConnection Disabled by No response No response No response /sig
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
there is a race shutting down the socks5 server

Discussion:
// be sure to unset environment variable https_proxy (if exported) before testing, otherwise the testing will fail unexpectedly. func TestRoundTripSocks5AndNewConnection(t *testing.T) { <del> t.Skip("Flake https://issues.k8s.io/107708") </del> localhostPool := localhostCertPool(t) for _, redirect := range []bool{false, true} {

if err != nil { t.Fatalf("socks5Server: proxy_test: Listen: %v", err) } <del> defer func() { close(closed) l.Close() }() </del> <ins> defer l.Close() </ins> go func(shoulderror bool) { conn, err := l.Accept()

} if err := proxyHandler.ServeConn(conn); err != nil && !shoulderror { <ins> // If the connection request is closed before the channel is closed // the test will fail with a ServeConn error. Since the test only return // early if expects shouldError=true, the channel is closed at the end of // the test, just before all the deferred connections Close() are executed. </ins> if isClosed() { return }

t.Fatalf("unexpected proxy user: %v", authUser) } } <ins> // The channel must be closed before any of the connections are closed close(closed) </ins> }) } })
Change:
pull-kubernetes-unit ~1 day since merging of Test introduced in /sig network
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
/cc
ahhhg let me fix it
oh, I will take a look.

Discussion:
return false } <ins> // return the size of the list func (q *graceTerminateRSList) len() int { q.lock.Lock() defer q.lock.Unlock() return len(q.list) } </ins> func (q *graceTerminateRSList) flushList(handler func(rsToDelete *listItem) (bool, error)) bool { q.lock.Lock() defer q.lock.Unlock()

import ( "fmt" <del> netutils "k8s.io/utils/net" </del> "reflect" "testing" <ins> netutils "k8s.io/utils/net" </ins> utilipvs "k8s.io/kubernetes/pkg/util/ipvs" utilipvstest "k8s.io/kubernetes/pkg/util/ipvs/testing" )

} func Test_RaceTerminateRSList(t *testing.T) { <del> ipvs := &utilipvstest.FakeIPVS{} </del> <ins> ipvs := utilipvstest.NewFake() </ins> gracefulTerminationManager := NewGracefulTerminationManager(ipvs) <ins> // run in parallel to cause the race </ins> go func() { for i := 1; i <= 10; i++ { <del> for j := 1; i <= 100; j++ { gracefulTerminationManager.rsList.add(makeListItem(i, j)) </del> <ins> for j := 1; j <= 100; j++ { item := makeListItem(i, j) gracefulTerminationManager.rsList.add(item) </ins> } } }() <del> if !gracefulTerminationManager.rsList.flushList(gracefulTerminationManager.deleteRsFunc) { </del> <ins> // wait until the list has some elements for gracefulTerminationManager.rsList.len() < 20 { } // fake the handler to avoid the check against the IPVS virtual servers fakeHandler := func(rsToDelete *listItem) (bool, error) { return true, nil } if !gracefulTerminationManager.rsList.flushList(fakeHandler) { </ins> t.Error("failed to flush entries") } }
Change:
Because of this scheme mutation, this leads to concurrent use of the same scheme to cause the program to panic. It would be ideal to do this in some concurrent safe manner or add a warning or similar
/sig api-machinery
/assign
/assign /triage accepted

Discussion:
eventRecorder := record.NewFakeRecorder(100) eventRecorder.IncludeObject = true <del> metadataClient := fakemetadata.NewSimpleMetadataClient(legacyscheme.Scheme) </del> <ins> metadataClient := fakemetadata.NewSimpleMetadataClient(fakemetadata.NewTestScheme()) </ins> tweakableRM := meta.NewDefaultRESTMapper(nil) tweakableRM.AddSpecific(

"k8s.io/client-go/discovery" "k8s.io/client-go/dynamic" "k8s.io/client-go/kubernetes/fake" <del> scheme "k8s.io/client-go/kubernetes/scheme" </del> "k8s.io/client-go/metadata" metadatafake "k8s.io/client-go/metadata/fake" restclient "k8s.io/client-go/rest"

} return false, nil, nil } <del> mockMetadataClient := metadatafake.NewSimpleMetadataClient(scheme.Scheme) </del> <ins> mockMetadataClient := metadatafake.NewSimpleMetadataClient(metadatafake.NewTestScheme()) </ins> mockMetadataClient.PrependReactor("delete-collection", "flakes", ns1FlakesNotFound) mockMetadataClient.PrependReactor("list", "flakes", ns1FlakesNotFound)

UpdateFake(obj *metav1.PartialObjectMetadata, opts metav1.UpdateOptions, subresources ...string) (*metav1.PartialObjectMetadata, error) } <ins> // NewTestScheme creates a unique Scheme for each test. func NewTestScheme() *runtime.Scheme { return runtime.NewScheme() } </ins> // NewSimpleMetadataClient creates a new client that will use the provided scheme and respond with the // provided objects when requests are made. It will track actions made to the client which can be checked // with GetActions().

testAPIVersion = "testgroup/testversion" ) <del> var scheme *runtime.Scheme func init() { scheme = runtime.NewScheme() metav1.AddMetaToScheme(scheme) } </del> func newPartialObjectMetadata(apiVersion, kind, namespace, name string) *metav1.PartialObjectMetadata { return &metav1.PartialObjectMetadata{ TypeMeta: metav1.TypeMeta{

} func TestList(t *testing.T) { <ins> scheme := NewTestScheme() metav1.AddMetaToScheme(scheme) </ins> client := NewSimpleMetadataClient(scheme, newPartialObjectMetadata("group/version", "TheKind", "ns-foo", "name-foo"), newPartialObjectMetadata("group2/version", "TheKind", "ns-foo", "name2-foo"),

} func (tc *patchTestCase) runner(t *testing.T) { <ins> scheme := NewTestScheme() metav1.AddMetaToScheme(scheme) </ins> client := NewSimpleMetadataClient(scheme, tc.object) resourceInterface := client.Resource(schema.GroupVersionResource{Group: testGroup, Version: testVersion, Resource: testResource}).Namespace(testNamespace)

timeout := time.Duration(3 * time.Second) ctx, cancel := context.WithTimeout(context.Background(), timeout) defer cancel() <del> scheme := runtime.NewScheme() </del> <ins> scheme := fake.NewTestScheme() </ins> metav1.AddMetaToScheme(scheme) informerReciveObjectCh := make(chan *metav1.PartialObjectMetadata, 1) objs := []runtime.Object{}
Change:
$ make test-e2e-node fails with an error because of the docker deprecation. I think we have to fix the default options for helper scripts. $ make test-e2e-node succeeds in common cases by default. $ make test-e2e-node No response_ <details</details<details</details<details</details<details</details<details</details<details</details/assign
/sig node
/cc
/assign
/triage accepted /assign /priority important-soon

Discussion:
#  TIMEOUT: For REMOTE=true only. How long (in golang duration format) to wait #    for ginkgo tests to complete. Defaults to 45m. #  PARALLELISM: The number of ginkgo nodes to run.  Defaults to 8. <del> #  RUNTIME: Container runtime to use (eg. docker, remote). #    Defaults to "docker". </del> #  CONTAINER_RUNTIME_ENDPOINT: remote container endpoint to connect to. <del> #    Used when RUNTIME is set to "remote". </del> <ins> #    Defaults to "/run/containerd/containerd.sock". </ins> #  IMAGE_SERVICE_ENDPOINT: remote image endpoint to connect to, to prepull images. #    Used when RUNTIME is set to "remote". #  IMAGE_CONFIG_FILE: path to a file containing image configuration.

artifacts="${ARTIFACTS:-"/tmp/_artifacts/$(date +%y%m%dT%H%M%S)"}" remote=${REMOTE:-"false"} remote_mode=${REMOTE_MODE:-"gce"} <del> container_runtime_endpoint=${CONTAINER_RUNTIME_ENDPOINT:-""} </del> <ins> container_runtime_endpoint=${CONTAINER_RUNTIME_ENDPOINT:-"unix:///run/containerd/containerd.sock"} </ins> image_service_endpoint=${IMAGE_SERVICE_ENDPOINT:-""} run_until_failure=${RUN_UNTIL_FAILURE:-"false"} test_args=${TEST_ARGS:-""}
Change:
Within kube-apiserver the flag is referenced in the help string but this flag does not exist kube-apiserver should reference the correct flag Corresponding kubernetes/website documentation issue/PR are: <details</detailsN/A N/A <detailsDownloaded and extracted from release binary </detailsN/A N/A
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 docs /sig cli

Discussion:
"ServiceAccount tokens. The specified file can contain multiple keys, and the flag can "+ "be specified multiple times with different files. If unspecified, "+ "--tls-private-key-file is used. Must be specified when "+ <del> "--service-account-signing-key is provided") </del> <ins> "--service-account-signing-key-file is provided") </ins> fs.BoolVar(&o.ServiceAccounts.Lookup, "service-account-lookup", o.ServiceAccounts.Lookup, "If true, validate ServiceAccount tokens exist in etcd as part of authentication.")
Change:
The Kubelet panics when: 's started with the option; a CSI volume is attached to a Node. From the Kubelet logs: Either document that this is not supported (and stop the panic'ing) or support and test this use case. kubelet with the option set. a CSI PVC and use it in a pod. No response <details</details<detailsany </details<details</details<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 storage
/assign

Discussion:
var _ volume.DeviceMounter = &csiAttacher{} func (c *csiAttacher) Attach(spec *volume.Spec, nodeName types.NodeName) (string, error) { <ins> _, ok := c.plugin.host.(volume.KubeletVolumeHost) if ok { return "", errors.New("attaching volumes from the kubelet is not supported") } </ins> if spec == nil { klog.Error(log("attacher.Attach missing volume.Spec")) return "", errors.New("missing spec")

var _ volume.DeviceUnmounter = &csiAttacher{} func (c *csiAttacher) Detach(volumeName string, nodeName types.NodeName) error { <ins> _, ok := c.plugin.host.(volume.KubeletVolumeHost) if ok { return errors.New("detaching volumes from the kubelet is not supported") } </ins> var attachID string var volID string
Change:
/kind failing-test /kind bug /sig api-machinery
/assign
hmm... latest run of the count10 job with this commit failed:
Interesting, that's a different TestRoundTrip? :eyes:
It seems to be getting lost here:
yeah... this is squirrely... that test is doing the following: internal types them to an openapi struct (which populates the extension pointing to internal structs) that to openapi json (which serializes Rule and Message in upper-case because there are no json tags on that struct) that to v1 JSONSchemaProps, which expects those fields to be and
I'll open another PR strengthening the test, and will tag in to figure out what the right thing to do here is this is the first structured extension we're adding that had subfields where capitalization mattered... I'm not 100% sure what we're doing here (serializing the internal types) is correct
PR in progress in
/triage accepted

Discussion:
**out = **in } <ins> if in.XValidations != nil { in, out := &in.XValidations, &out.XValidations *out = make([]ValidationRule, len(*in)) copy(*out, *in) } </ins> return out }
Change:
ran instead of and got no error and then though that was the right version kubectl should fail for unexpected extra arguments
/sig cli
/assign
/triage accepted

Discussion:
Example: versionExample, Run: func(cmd *cobra.Command, args []string) { cmdutil.CheckErr(o.Complete(f, cmd)) <del> cmdutil.CheckErr(o.Validate()) </del> <ins> cmdutil.CheckErr(o.Validate(args)) </ins> cmdutil.CheckErr(o.Run()) }, }

} // Validate validates the provided options <del> func (o *Options) Validate() error { </del> <ins> func (o *Options) Validate(args []string) error { if len(args) != 0 { return errors.New(fmt.Sprintf("extra arguments: %v", args)) } </ins> if o.Output != "" && o.Output != "yaml" && o.Output != "json" { return errors.New(`--output must be 'yaml' or 'json'`) }

if err := o.Complete(tf, &cobra.Command{}); err != nil { t.Errorf("Unexpected error: %v", err) } <del> if err := o.Validate(); err != nil { </del> <ins> if err := o.Validate(nil); err != nil { </ins> t.Errorf("Unexpected error: %v", err) } <ins> if err := o.Validate([]string{"extraParameter0"}); !strings.Contains(err.Error(), "extra arguments") { t.Errorf("Unexpected error: should fail to validate the args length greater than 0") } </ins> if err := o.Run(); err != nil { t.Errorf("Cannot execute version command: %v", err) }
Change:
There seems to be a race condition in the following unit test The race happens between read at and write at No race condition CI logs where race was detected: <details</details<details</details<details</details<details</details<details</details<details</details
/sig node /cc
/remove-kind bug /kind flake (potential flake, did not use the flake template because CI is green for this test)
A related pr merged
/assign
Thanks for checking again. fyi
Maybe we need something like this:
are u working on resolve this issue? i wonder why doesn't face a race condition
I think he's still working on it. The race condition doesn't happen there because doesn't start another go routine. In the kubelet's case however, the write part of the race condition happens in another go routine that is spawned: write:
/triage accepted /priority important-soon
seen in this spiked in the last couple days - is this related to the klog bump ()? cc /priority critical-urgent /milestone v1.24
increasing priority since it is impacting test runs, and marking as blocker until root caused and we understand whether it is prod-impacting
/assign ^ I'll take this one up on monday - still feel free to open a PR if you have WIP investigation/research
please see if you have comments/inputs on the already open one.
I don't see how the klog bump could have made it worse. Perhaps the change around the flush daemon changed some timing conditions, but that's a rather wild guess. These tests have been faulty all along and need to be fixed. What klog can do is support unit tests like this better. I've opened two issues: short term: long term as it depends on contextual logging:
I think it's safe to remove the release-blocker here. The root cause is largely as explained here: (appears to be test-only)

Discussion:
} } <ins> type buffer struct { b  bytes.Buffer rw sync.RWMutex } func (b *buffer) String() string { b.rw.RLock() defer b.rw.RUnlock() return b.b.String() } func (b *buffer) Write(p []byte) (n int, err error) { b.rw.Lock() defer b.rw.Unlock() return b.b.Write(p) } </ins> func Test_managerImpl_processShutdownEvent(t *testing.T) { var ( probeManager   = probetest.FakeManager{}

l := klog.Level(1) l.Set("1") // hijack the klog output <del> tmpWriteBuffer := bytes.NewBuffer(nil) </del> <ins> tmpWriteBuffer := new(buffer) </ins> klog.SetOutput(tmpWriteBuffer) klog.LogToStderr(false)
Change:
[x] Test PR : [x] Two weeks soak end date : 6 April 2022 [X] Test promotion PR : According to this APIsnoop query, there are still some remaining Job status endpoints which are untested. There are conformance tests for CronJob status endpoints already the existing as a template, a new for job test has been created. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test 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
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
pod. Modify the labels of one of the Job's Pods. The Job MUST release the Pod. release: v1.16 file: test/e2e/apps/job.go <ins> - testname: Jobs, apply changes to status codename: '[sig-apps] Job should apply changes to a job status [Conformance]' description: Attempt to create a running Job which MUST succeed. Attempt to patch the Job status to include a new start time which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with a new start time which MUST succeed. Attempt to read its status sub-resource which MUST succeed release: v1.24 file: test/e2e/apps/job.go </ins> - testname: Ensure Pods of an Indexed Job get a unique index. codename: '[sig-apps] Job should create pods for an Indexed job with completion indexes and specified hostname [Conformance]'

framework.ExpectEqual(successes, largeCompletions, "expected %d successful job pods, but got  %d", largeCompletions, successes) }) <del> ginkgo.It("should apply changes to a job status", func() { </del> <ins> /* Release: v1.24 Testname: Jobs, apply changes to status Description: Attempt to create a running Job which MUST succeed. Attempt to patch the Job status to include a new start time which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with a new start time which MUST succeed. Attempt to read its status sub-resource which MUST succeed */ framework.ConformanceIt("should apply changes to a job status", func() { </ins> ns := f.Namespace.Name jClient := f.ClientSet.BatchV1().Jobs(ns)
Change:
Since we switched from dockershim to containerd, my cluster seems to come up okay but pods get stuck in ContainerCreating. When I investigated further, I found Most dependencies of launching a cluster are installed automatically. In this case, it seems we don't get the CNI plugins installed and set up as needed. /cc /sig node network Pod should have been created as expected. Try to create pods on a system with local-up-cluster without CNI plugins already installed. No response <details</details<detailsN/A </details<details</details<detailshack/local-up- </details<details</details<details</details
maybe also /sig testing ?
cc patron saint of local-up-
/assign
I think it's as simple as checking if exists (or wherever it's looking for the CNI plugins) and if not, downloading the latest Linux version for the appropriate arch of
already working on installing cni plugin for the local-up ci job but if the script is running by user, doesn't we make an assumption that user will install cni plugins along with container runtime?
/assign the local e2e job is now working, have to refine the script we are anyways installing cni for the ci job, will add a provision so that users can also install.
/triage accepted
similar bug:

Discussion:
EOF } <ins> function install_cni_if_needed { echo "Checking CNI Installation at /opt/cni/bin" if ! command -v /opt/cni/bin/loopback &> /dev/null ; then echo "CNI Installation not found at /opt/cni/bin" install_cni fi } </ins> # If we are running in the CI, we need a few more things before we can start if [[ "${KUBETEST_IN_DOCKER:-}" == "true" ]]; then echo "Preparing to test ..."

fi if [[ "${START_MODE}" != "nokubelet" ]]; then <ins> install_cni_if_needed </ins> ## TODO remove this check if/when kubelet is supported on darwin # Detect the OS name/arch and display appropriate error. case "$(uname -s)" in
Change:
Similar to issue , building kubernetes1.23 resulted in 1 variation: builds should be fully determined by inputs on openSUSE or Debian, This bug was found while working on . <details23.0 </details<details</details<details</details<details</details<details</details<details</details
/sig release /area build-release
/assign
/sig cli
/triage accepted /assign

Discussion:
import ( "fmt" "os" <ins> "sort" </ins> "strings" "github.com/spf13/cobra"

for format := range columnsFormats { formats = append(formats, format) } <ins> sort.Strings(formats) </ins> return formats }