jiebi/CodeConvo huggingface dataset:
Change:
What happened: On our Ubuntu 18.04 build machines(with bash 4.2), build failed with error: What you expected to happen: build succeeds without error. How to reproduce it (as minimally and precisely as possible): On a Ubuntu 18.04 machine with the latest bash installed from official repo, do make by Anything else we need to know?: This is related to PR
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 release
version 5 was forced here:
The support of test was in bash version 4.2. It would be better to limit the mimimum verison to 4.2+, since some people, including us, are using Ubuntu 18.04 with bash 4.x to do the build. Thanks.
Or better yet use another method like; BTW I removed this flawed test and build happily on Ubuntu 18 without any problem.
i do not disagree with that. looks like the right people are already assigned to your PR.
This is breaking downstream CIs, I´ve found this today in one of thems is not possible to relax this to 4.2? /sig-testing
Better to not use the "test -v" options at all since it is completely unnecessary, see It is not very user-friendly to enforce a global upgrade when there is absolutely no need. Ubuntu 18 has 4.2 but others may not.
:)
Heh , that was fast :)
this is actually not an equivilant check, but it is possible to implement one without using -v I left a comment on the original PR with how to do this.
see: reports if the variable was set_, which includes In this case I do think the intent was to check if the variable was set or not. It's still possible to do without but it's a big more ... arcane. Kubernetes has long required a reasonably up to date bash FWIW, on macOS you cannot use the system bash, and for a while you couldn't use debian stable's bash to build kubernetes as it had an array bug (4.0 IIRC). I don't think we have a clear support policy here, and I think this is a good reason to reconsider writing large volumes of bash

Discussion:
# function kube::util::ensure-bash-version { # shellcheck disable=SC2004 <del> if ((${BASH_VERSINFO[0]}<5)); then echo "ERROR: This script requires a minimum bash version of 5.0" </del> <ins> if ((${BASH_VERSINFO[0]}<4)) || ( ((${BASH_VERSINFO[0]}==4)) && ((${BASH_VERSINFO[1]}<2)) ); then echo "ERROR: This script requires a minimum bash version of 4.2, but got version of ${BASH_VERSINFO[0]}.${BASH_VERSINFO[1]}" </ins> exit 1 fi }
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: () Which test(s) are failing: Since when has it been failing: Jan 25 6:25AM PST was the first unsuccessful run Testgrid link: https://k8s- Reason for failure: . These are the logs from after the pod was . Anything else we need to know: Related to and (possibly?) Latest failing run as of writing: /sig network /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

Discussion:
s.Spec.Ports[0].Port++ }) framework.ExpectNoError(err) <del> if int(udpService.Spec.Ports[0].Port) == svcPort { framework.Failf("UDP Spec.Ports[0].Port (%d) did not change", udpService.Spec.Ports[0].Port) </del> <ins> svcPortOld := svcPort svcPort = int(udpService.Spec.Ports[0].Port) if svcPort == svcPortOld { framework.Failf("UDP Spec.Ports[0].Port (%d) did not change", svcPort) </ins> } if int(udpService.Spec.Ports[0].NodePort) != udpNodePort { framework.Failf("UDP Spec.Ports[0].NodePort (%d) changed", udpService.Spec.Ports[0].NodePort)
Change:
What happened: egress selector logs HTTP Connect mode in all cases regardless of whether GRPC mode is used or not. This should be changed to look at the mode before logging.
/sig api-machinery
/assign
/triage accepted

Discussion:
return directDialer } return func(ctx context.Context, network, addr string) (net.Conn, error) { <del> trace := utiltrace.New(fmt.Sprintf("Proxy via HTTP Connect over %s", d.options.transport), utiltrace.Field{Key: "address", Value: addr}) </del> <ins> trace := utiltrace.New(fmt.Sprintf("Proxy via %s protocol over %s", d.options.protocol, d.options.transport), utiltrace.Field{Key: "address", Value: addr}) </ins> defer trace.LogIfLong(500 * time.Millisecond) start := egressmetrics.Metrics.Clock().Now() proxier, err := d.connector.connect()
Change:
<!-- 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: I upgraded from 1.15 and am using prometheus to scrape my pods via the proxy functionality. Previously no error message was being printed, now with 1.19.9 every try results in an error: Example url: https://x.x.x.x:6443/api/v1/namespaces/staging/pods/proxy-app--6sxfx:80/proxy/metrics What you expected to happen: No error message to be logged, since the apiserver anyways returns a corresponding http error code. The least thing I would expect it not to log as an error, but as a debug or info log, since it doesn't actually represent an error. It returns something like that: How to reproduce it (as minimally and precisely as possible): Call the proxy functionality on an endpoint that does not listen and will refuse the connection. Anything else we need to know?: There is a lot of other issues with a similar error message, but I believe they are not interconnected since this has explicitly todo with an error raised from the proxy functionality. Environment: Kubernetes version (use ): 1.19.9 Cloud provider or hardware configuration: on premise OS (e.g: ): CentOs 7 Kernel (e.g. ): 5.4.60
/sig api-machinery
/cc /triage accepted
/assign

Discussion:
"golang.org/x/net/html/atom" "k8s.io/klog/v2" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/util/net" "k8s.io/apimachinery/pkg/util/sets" )

resp, err := rt.RoundTrip(req) if err != nil { <del> return nil, fmt.Errorf("error trying to reach service: %w", err) </del> <ins> return nil, errors.NewServiceUnavailable(fmt.Sprintf("error trying to reach service: %v", err)) </ins> } if redirect := resp.Header.Get("Location"); redirect != "" {
Change:
In our Tanzu Supervisor Cluster k8s setup, we observe that the "should verify that a failing subpath expansion can be modified during the lifecycle of a container" conformance test fails. The root-cause seems to be that the test is updating the pod annotations, thereby resulting in removing the other annotations present in the pod object. Removing the custom annotations that we use causes the test to fail during pod deletion. Should this test perhaps use Patch instead of Update so that the annotations are merged and not replaced? Thanks ginkgo.By("updating the pod") podClient.Update(pod.ObjectMeta.Name, func(pod *v1.Pod) { pod.ObjectMeta.Annotations = map[string]string{"mysubpath": "mypath"} })
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 /sig conformance I personally agree that it should not remove existing annotations, but better ask the test owners
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /sig conformance I personally agree that it should not remove existing annotations, but better ask the test owners 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
May I request the original author to weigh in on this? Thank you.
I dont have any issues with the code change to a merge but what would bother me is that conformance tests are being altered by outside influences which doesnt seem particularly right. I think this would be for the sig storage owners to decide
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

Discussion:
ginkgo.By("updating the pod") podClient.Update(pod.ObjectMeta.Name, func(pod *v1.Pod) { <del> pod.ObjectMeta.Annotations = map[string]string{"mysubpath": "mypath"} </del> <ins> if pod.ObjectMeta.Annotations == nil { pod.ObjectMeta.Annotations = make(map[string]string) } pod.ObjectMeta.Annotations["mysubpath"] = "mypath" </ins> }) ginkgo.By("waiting for pod running")
Change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: (regardlessoffailurepolicy)and_fail Testgrid link: Reason for failure: and Anything else we need to know: Spyglass: <!-- Please see the deflaking doc () for more guidance! --
/sig api-machinery /area apiserver
Can confirm this PR:
/assign
/triage accepted
The kube-apiserver processing flow is as follows, (non-critical paths are omitted) ... // other filters parse the http client timeout setting, sets the Ctx with Deadline in the http.Request ...// other filters select the http.Request.Context().Done() Pay attention to the processing logic in . Although the Context of http.Request has been cancelled, the Mutex on baseTimeoutWriter needs to be obtained between entering the function. The inner-handler may have written , ready to write , but the current code flow thinks that it should be Panic quickly, and it is recovered by and sends http2.Reset to the Client. As a result, a appears on the client side.
Currently seeing it in periodic and in presubmit for
Regardless of WithCache or WithoutCache, here is not reasonable.
/priority important-soon /milestone v1.21
PS: There were some recent failures:
/remove-priority important-soon /priority critical-urgent top flake for pull-kubernetes-integration per: triage link: FYI
may be one fix, may also be necessary (thanks for opening these
I believe that can effectively repair the issue, but currently is not the key PR to fix the issue.

Discussion:
validatingWebhooks []testWebhook expectInvocations  []invocation expectError        bool <del> errorContains      string </del> <ins> errorContainsAnyOf []string </ins> }{ { name:           "minimum of request timeout or webhook timeout propagated",

expectInvocations: []invocation{ {path: "/mutating/1/5s", timeoutSeconds: 3}, // from request }, <del> expectError:   true, errorContains: "the server was unable to return a response in the time allotted", </del> <ins> expectError: true, errorContainsAnyOf: []string{ // refer to https://github.com/kubernetes/kubernetes/issues/98606#issuecomment-774832633 // for the reason for triggering this scenario "stream error", "the server was unable to return a response in the time allotted", }, </ins> }, }

if err == nil { t.Fatalf("expected error but got none") } <del> if tt.errorContains != "" { if !strings.Contains(err.Error(), tt.errorContains) { t.Errorf("expected an error saying %q, but got: %v", tt.errorContains, err) </del> <ins> expected := false if len(tt.errorContainsAnyOf) != 0 { for _, errStr := range tt.errorContainsAnyOf { if strings.Contains(err.Error(), errStr) { expected = true break } </ins> } } <ins> if !expected { t.Errorf("expected the error to be any of %q, but got: %v", tt.errorContainsAnyOf, err) } </ins> return }
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: The overall job Since when has it been failing: Sometime between Jan 29 07:00 PST (commit ) and 16:13 PST (commit ) There are some runs that could not be scheduled on a node between these two runs, so it's not clear exactly when it started failing Testgrid link: https://k8s- Reason for failure: And then it spits out all the possible Docker options and commands. Anything else we need to know: Feels like it may be related to ? -- That was merged Jan 28 though, and there were successful runs between that and this run Spyglass example for failure: Contrast with Spyglass example for last success: /sig release
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 confirm that I hit the same issue in a CI that builds kubernetes using
is removed in docker 20.10?
Looking into this /assign xref
xref /cc
Yeah docker buildx is not initialized within this job. Like mentioned, we probably broke other CI's too. I'm wondering if a init script would help us here, but I'm just trying to find out what the technical differences between the and are.
/assign

Discussion:
echo "COPY nsswitch.conf /etc/" >> "${docker_file_path}" fi <del> "${DOCKER[@]}" buildx build  </del> <ins> DOCKER_CLI_EXPERIMENTAL=enabled "${DOCKER[@]}" buildx build  </ins> --platform linux/"${arch}"  --load ${docker_build_opts:+"${docker_build_opts}"}  -q 

cd ${TEMP_DIR} && sed -i.back "s|BASEIMAGE|${BASEIMAGE}|g" Dockerfile <del> docker buildx build  </del> <ins> DOCKER_CLI_EXPERIMENTAL=enabled docker buildx build  </ins> --platform linux/${ARCH}  --load  --pull
Change:
Which jobs are flaking: ci-kubernetes-cached-make-test ci-kubernetes-generate-make-test-count10 pull-kubernetes-unit Which test(s) are flaking: TestPriorityAndFairnessWithPanicRecoveryAndTimeoutFilter Testgrid link: Reason for failure: Data race: Reproduced in ~2% of runs with : Triage board: /sig api-machinery
cc
The test is timing out after 300 seconds, but I couldn't reproduce this over 1000 runs (with and without )
(In case it's not clear from comments: the actual failure is the timeout, not the panic as stated in the OP.)
Finally reproduced the issue locally after many runs:
thank you for reproducing it! are you planning to try to fix it? Thanks!
I tried to, but I couldn't find the root cause. I'll take another look today. /assign
/accept triage
/triage accepted
/milestone v1.21 /priority critical-urgent Raising priority and adding to the milestone for triage since this looks like a data race in non-test code in a default-enabled filter. This unit test did not exist in 1.20 so it's not clear if this is a regression in 1.21 or not. If this issue existed in 1.20, priority can be lowered to important-soon and it does not block 1.21, but should be fixed and picked to 1.20.x and 1.21.x
I'm afraid I won't have the time to look into this in the short term. Unassigning so that someone else can take a look. /unassign
(looking at it now) /assign
found the data race and put out a quick fix for this:
I ran , and it looks good so far:
cherry-picked it for - Can someone please let me know if I did it correctly?

Discussion:
// request's context's Done channel gets closed by the time // the request is done being processed. doneCh := ctx.Done() <ins> // Retrieve the queueset configuration name while we have the lock // and use it in the goroutine below. configName := qs.qCfg.Name </ins> if doneCh != nil { qs.preCreateOrUnblockGoroutine() go func() {

// known that the count does not need to be accurate. // BTW, the count only needs to be accurate in a test that // uses FakeEventClock::Run(). <del> klog.V(6).Infof("QS(%s): Context of request %q %#+v %#+v is Done", qs.qCfg.Name, fsName, descr1, descr2) </del> <ins> klog.V(6).Infof("QS(%s): Context of request %q %#+v %#+v is Done", configName, fsName, descr1, descr2) </ins> qs.cancelWait(req) qs.goroutineDoneOrBlocked() }()
Change:
<!-- 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: panicked with "invalid memory address or nil pointer dereference", resulting in crash-looping. What you expected to happen: to gracefully handle nil-valued variables. How to reproduce it (as minimally and precisely as possible): Create a object with a field that, when passed to , returns . Anything else we need to know?: This is the offending code: The nil pointer dereference occurred on line 473. Environment: Kubernetes version (use ): 1.17.14 Cloud provider or hardware configuration: GKE OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig apps
/cc /triage accepted
/assign

Discussion:
// IMPORTANT NOTE : the returned pods should NOT be modified. func (dc *DisruptionController) getPodsForPdb(pdb *policy.PodDisruptionBudget) ([]*v1.Pod, error) { sel, err := metav1.LabelSelectorAsSelector(pdb.Spec.Selector) <del> if sel.Empty() { return []*v1.Pod{}, nil } </del> if err != nil { return []*v1.Pod{}, err } <ins> if sel.Empty() { return []*v1.Pod{}, nil } </ins> pods, err := dc.podLister.Pods(pdb.Namespace).List(sel) if err != nil { return []*v1.Pod{}, err

} } <ins> func TestInvalidSelectors(t *testing.T) { testCases := map[string]struct { labelSelector *metav1.LabelSelector }{ "illegal value key": { labelSelector: &metav1.LabelSelector{ MatchLabels: map[string]string{ "k8s.io/too/many/slashes": "value", }, }, }, "illegal operator": { labelSelector: &metav1.LabelSelector{ MatchExpressions: []metav1.LabelSelectorRequirement{ { Key:      "foo", Operator: metav1.LabelSelectorOperator("illegal"), Values:   []string{"bar"}, }, }, }, }, } for tn, tc := range testCases { t.Run(tn, func(t *testing.T) { dc, ps := newFakeDisruptionController() pdb, pdbName := newMinAvailablePodDisruptionBudget(t, intstr.FromInt(3)) pdb.Spec.Selector = tc.labelSelector add(t, dc.pdbStore, pdb) dc.sync(pdbName) ps.VerifyPdbStatus(t, pdbName, 0, 0, 0, 0, map[string]metav1.Time{}) }) } } </ins> // waitForCacheCount blocks until the given cache store has the desired number // of items in it. This will return an error if the condition is not met after a // 10 second timeout.
Change:
What would you like to be : // See , and // right address of restful-CORS- and restful-basic- in the comment of Why is this needed: the address of restful-CORS- and restful-basic- in the comment of is wrong now, this may affect reading codes. Thanks.
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
/kind cleanup /sig docs /assign

Discussion:
) // TODO: use restful.CrossOriginResourceSharing <del> // See github.com/emicklei/go-restful/blob/master/examples/restful-CORS-filter.go, and // github.com/emicklei/go-restful/blob/master/examples/restful-basic-authentication.go </del> <ins> // See github.com/emicklei/go-restful/blob/master/examples/cors/restful-CORS-filter.go, and // github.com/emicklei/go-restful/blob/master/examples/basicauth/restful-basic-authentication.go </ins> // Or, for a more detailed implementation use https://github.com/martini-contrib/cors // or implement CORS at your proxy layer.
Change:
Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: Triage: Spyglass: /sig api-machinery
/sig scheduling /remove-sig api-machinery I get the log from the artifacts. ResourceQuota check for best-effort pod failed for a pod that is not scheduled due to below error that is expected as The scheduling error is expected. no error/warning messages in kube controller manager with resourcequotacontroller. The case was failed after 30 seconds. Try to fix it like for configmap check. It seems that resource quota status/used updating is not that quick.
/remove-sig scheduling /sig api-machinery
BTW, if we want to fix it in kube-controller-manager side. Increase the namespace syncs concurrent may help If there are some metrics, it can be proved to be right or wrong.
/cc /triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /cc /triage accept 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
/triage accepted
past weeks looks good to me, can we move it to observe?

Discussion:
const ( // how long to wait for a resource quota update to occur <del> resourceQuotaTimeout = 30 * time.Second </del> <ins> resourceQuotaTimeout = time.Minute </ins> podName              = "pfpod" )

// updateResourceQuotaUntilUsageAppears updates the resource quota object until the usage is populated // for the specific resource name. func updateResourceQuotaUntilUsageAppears(c clientset.Interface, ns, quotaName string, resourceName v1.ResourceName) error { <del> return wait.Poll(framework.Poll, 1*time.Minute, func() (bool, error) { </del> <ins> return wait.Poll(framework.Poll, resourceQuotaTimeout, func() (bool, error) { </ins> resourceQuota, err := c.CoreV1().ResourceQuotas(ns).Get(context.TODO(), quotaName, metav1.GetOptions{}) if err != nil { return false, err
Change:
What happened: Hi, I use to spawn the Kubernetes clusters inside the Kubernetes. Cert-manager is used to generate the certificates. Certificates mounted into pod as standard secret volume. This has no section but use instead: During the bootstrap this phase is executed by kubeadm: Which is overriding config in namespace: In result has no any CA, which make other nodes not possible to join the cluster: What you expected to happen: has correct CA-file new nodes are able to join How to reproduce it (as minimally and precisely as possible): put CA into file remove certificate-authority-data from describe path to the CA in parameter in Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: on-premise OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 cluster-lifecycle /assign neolit123

Discussion:
if err != nil { return errors.Wrap(err, "failed to load admin kubeconfig") } <ins> if err = clientcmdapi.FlattenConfig(adminConfig); err != nil { return err } </ins> adminCluster := adminConfig.Contexts[adminConfig.CurrentContext].Cluster // Copy the cluster from admin.conf to the bootstrap kubeconfig, contains the CA cert and the server URL