jiebi/CodeConvo huggingface dataset:
Change:
After the gce-master-scale-performance started failing with errors like: https://k8s- In a sample run I see a lot of errors like: in konnectivity-server logs: Looks like we have to increase QPS limit for konnectivity-server, do we have a flag (kube-env?) for that? /cc /assign
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 cloud-provider
/priority critical-urgent
We may need to re-open this, if there are still uncovered problems (or if we need to re-tune) after watching next test runs.
Wow, thanks a lot for such a rapid fix. Much appreciated!

Discussion:
"--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt", "--proxy-server-host=__APISERVER_IP__", "--proxy-server-port=8132", <ins> "--sync-interval=5s", "--sync-interval-cap=30s", "--probe-interval=5s", </ins> "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token" ] env:

params+=("--agent-service-account=konnectivity-agent") params+=("--kubeconfig=/etc/srv/kubernetes/konnectivity-server/kubeconfig") params+=("--authentication-audience=system:konnectivity-server") <ins> params+=("--kubeconfig-qps=75") params+=("--kubeconfig-burst=150") </ins> konnectivity_args="" for param in "${params[@]}"; do konnectivity_args+=", "${param}""
Change:
When using Graceful Node Shutdown feature, status and reason of "shutdown" pod are confusing for users. See where I attempt to address this confusion by documenting the behavior. However, it would be great to improve messages. Perhaps the following renaming: Reason "Shutdown" is confusing because it may appear as a process of shutting down. Better message will also be useful. Reason and Message changed for pods terminated in response to Node shutdown. Shutdown the node and observer the pod status. KEP: kubernetes/enhancements /cc /sig node /help /good-first-issue Kubernetes version (use ): 1.19+ (with feature enabled)
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : #### What happened: /cc /sig node /help /good-first-issue Kubernetes version (use ): 1.19+ (with feature enabled) </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
/cc
/assign
/assign

Discussion:
) const ( <del> nodeShutdownReason          = "Shutdown" nodeShutdownMessage         = "Node is shutting, evicting pods" nodeShutdownNotAdmitMessage = "Node is in progress of shutting down, not admitting any new pods" dbusReconnectPeriod         = 1 * time.Second </del> <ins> nodeShutdownReason             = "Terminated" nodeShutdownMessage            = "Pod was terminated in response to imminent node shutdown." nodeShutdownNotAdmittedReason  = "NodeShutdown" nodeShutdownNotAdmittedMessage = "Pod was rejected as the node is shutting down." dbusReconnectPeriod            = 1 * time.Second </ins> ) var systemDbus = func() (dbusInhibiter, error) {

if nodeShuttingDown { return lifecycle.PodAdmitResult{ Admit:   false, <del> Reason:  nodeShutdownReason, Message: nodeShutdownNotAdmitMessage, </del> <ins> Reason:  nodeShutdownNotAdmittedReason, Message: nodeShutdownNotAdmittedMessage, </ins> } } return lifecycle.PodAdmitResult{Admit: true}

status := v1.PodStatus{ Phase:   v1.PodFailed, <del> Message: nodeShutdownMessage, </del> Reason:  nodeShutdownReason, <ins> Message: nodeShutdownMessage, </ins> } err := m.killPod(pod, status, &gracePeriodOverride)
Change:
/kind failing-test Not sure if flake. Gubernator is showing a big spike in failures that started 06/14 around 10:00 ~UTC~ PT. This seems to be when merged. Failed on my PR: /sig testing
/sig api-machinery
/cc
filed I'm hesistant to bump it all the way back to 240, if you follow back the original PR / issue trail I ran a number of iterations of testing and it really shouldn't take 240s. four minutes is ludicrous for unit testing one package.
there are 39 failures in the last day in from timeout :/ /priority critical-urgent
Did any timed-out run produce any logs?
we capture the test logs but itself doesn't appear to have any.
e.g. at random (from triage above) ="raw build-" I'm not sure this code emits any when it fails.
Likely it's timing out on some step, but I would have expected some logging from something related -- I was just going to look at the last thing logged and figure that something after that must be the culprit. Does that log capture stderr and stdout of the test invocations?
it should, e.g. see a different kind of failure with logs: we're running with json output formatting then through to junit, and prow will capture stdout/stderr of whatever is running within the job as build-
reopening to keep an eye on this.
sigh: 180s
it's doing better (all recent runs passed, looks like 3 flakes due to this since the PR merged this afternoon) but we may still want to bump it again
We're at 100% pass rate the past 3 hours but CI is not very active right now. still just 3 fails. If we have a similar rate tomorrow morning I'd opt for another small bump (maybe 180s -190s) to cover remaining limited flakes still over going all the way back to 4 minutes.
If we knew which sub test was slow when it is slow, that would possibly narrow it down to a haystack small enough to look for needles in.
dug into it locally, follow up in:
Fairly confident this is now fixed after
closing as fixed by
confirmed
example:
that run happened at the fix merged at

Discussion:
# TODO: This timeout should really be lower, this is a *long* time to test one # package, however pkg/api/testing in particular will fail with a lower timeout # currently. We should attempt to lower this over time. <del> KUBE_TIMEOUT=${KUBE_TIMEOUT:--timeout=170s} </del> <ins> KUBE_TIMEOUT=${KUBE_TIMEOUT:--timeout=180s} </ins> KUBE_COVER=${KUBE_COVER:-n} # set to 'y' to enable coverage collection KUBE_COVERMODE=${KUBE_COVERMODE:-atomic} # The directory to save test coverage reports to, if generating them. If unset,
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 --I noticed that the the code in for calculating the dR/dt, the derivative of R(t) with respect to t, called in the code , was not updated when the generalization for width was introduced. The should be between C and the sum of seats not the number of requests. See , where it says 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:
yes, i noticed it, I am going to open a PR. /assign
/triage accepted

Discussion:
// been advancing, according to the logic in `doc.go`. func (qs *queueSet) getVirtualTimeRatioLocked() float64 { activeQueues := 0 <del> reqs := 0 </del> <ins> seatsInUse := 0 </ins> for _, queue := range qs.queues { <del> reqs += queue.requestsExecuting </del> <ins> seatsInUse += queue.seatsInUse </ins> if queue.requests.Length() > 0 || queue.requestsExecuting > 0 { activeQueues++ }

if activeQueues == 0 { return 0 } <del> return math.Min(float64(reqs), float64(qs.dCfg.ConcurrencyLimit)) / float64(activeQueues) </del> <ins> return math.Min(float64(seatsInUse), float64(qs.dCfg.ConcurrencyLimit)) / float64(activeQueues) </ins> } // timeoutOldRequestsAndRejectOrEnqueueLocked encapsulates the logic required
Change:
junit output: full output with actual error (expand build- and grep around) we want the actual error to be included in the junit so it will be displayed at the top, right now the error at the top is confusing and useless. /sig testing
/assign

Discussion:
) # tell the user which we've selected and lint all scripts <ins> # The shellcheck errors are printed to stdout by default, hence they need to be redirected # to stderr in order to be well parsed for Junit representation by juLog function </ins> res=0 if ${HAVE_SHELLCHECK}; then echo "Using host shellcheck ${SHELLCHECK_VERSION} binary." <del> shellcheck "${SHELLCHECK_OPTIONS[@]}" "${all_shell_scripts[@]}" || res=$? </del> <ins> shellcheck "${SHELLCHECK_OPTIONS[@]}" "${all_shell_scripts[@]}" >&2 || res=$? </ins> else echo "Using shellcheck ${SHELLCHECK_VERSION} docker image." "${DOCKER}" run  --rm -v "${KUBE_ROOT}:${KUBE_ROOT}" -w "${KUBE_ROOT}"  "${SHELLCHECK_IMAGE}"  <del> shellcheck "${SHELLCHECK_OPTIONS[@]}" "${all_shell_scripts[@]}" || res=$? </del> <ins> shellcheck "${SHELLCHECK_OPTIONS[@]}" "${all_shell_scripts[@]}" >&2 || res=$? </ins> fi # print a message based on the result
Change:
Which jobs are flaking: Which test(s) are flaking: ! Testgrid link: Reason for failure: Anything else we need to know: /cc /sig network /sig scalability /priority important-soon
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
/assign

Discussion:
// GetEndpointNodeNames returns a string set of node names on which the // endpoints of the given Service are running. func (j *TestJig) GetEndpointNodeNames() (sets.String, error) { <ins> err := j.waitForAvailableEndpoint(ServiceEndpointsTimeout) if err != nil { return nil, err } </ins> endpoints, err := j.Client.CoreV1().Endpoints(j.Namespace).Get(context.TODO(), j.Name, metav1.GetOptions{}) if err != nil { return nil, fmt.Errorf("get endpoints for service %s/%s failed (%s)", j.Namespace, j.Name, err)
Change:
/cc Can and npd v0.8.8(with ) fix this problem? /sig node Example: node-problem-  /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
Yes, the and npd v0.8.8(with kubernetes/node-problem-detector) should fix this problem
/triage accepted /assign
There are other files that are needed to be updated, for reference Could you please update.

Discussion:
apiVersion: apps/v1 kind: DaemonSet metadata: <del> name: npd-v0.8.7 </del> <ins> name: npd-v0.8.8 </ins> namespace: kube-system labels: k8s-app: node-problem-detector <del> version: v0.8.7 </del> <ins> version: v0.8.8 </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile spec: selector: matchLabels: k8s-app: node-problem-detector <del> version: v0.8.7 </del> <ins> version: v0.8.8 </ins> template: metadata: labels: k8s-app: node-problem-detector <del> version: v0.8.7 </del> <ins> version: v0.8.8 </ins> kubernetes.io/cluster-service: "true" spec: containers: - name: node-problem-detector <del> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.7 </del> <ins> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.8 </ins> command: - "/bin/sh" - "-c"

### Hardcoded constants DEFAULT_CNI_VERSION='v0.9.1' DEFAULT_CNI_HASH='b5a59660053a5f1a33b5dd5624d9ed61864482d9dc8e5b79c9b3afc3d6f62c9830e1c30f9ccba6ee76f5fb1ff0504e58984420cc0680b26cb643f1cb07afbd1c' <del> DEFAULT_NPD_VERSION='v0.8.7' DEFAULT_NPD_HASH='853576423077bf72e7bd8e96cd782cf272f7391379f8121650c1448531c0d3a0991dfbd0784a1157423976026806ceb14ca8fb35bac1249127dbf00af45b7eea' </del> <ins> DEFAULT_NPD_VERSION='v0.8.8' DEFAULT_NPD_HASH='ba8315a29368bfc33bdc602eb02d325b0b80e295c8739da35616de5b562c372bd297a2553f3ccd4daaecd67698b659b2c7068a2d2a0b9418ad29233fb75ff3f2' </ins> DEFAULT_CRICTL_VERSION='v1.21.0' DEFAULT_CRICTL_HASH='e4fb9822cb5f71ab8f85021c66170613aae972f4b32030e42868fb36a3bc3ea8642613df8542bf716fad903ed4d7528021ecb28b20c6330448cd2bd2b76bd776' DEFAULT_MOUNTER_TAR_SHA='7956fd42523de6b3107ddc3ce0e75233d2fcb78436ff07a1389b6eaac91fb2b1b72a08f7a219eaf96ba1ca4da8d45271002e0d60e0644e796c665f99bb356516'

local -r npd_version="${DEFAULT_NPD_VERSION}" local -r npd_hash="${DEFAULT_NPD_HASH}" fi <del> local -r npd_tar="node-problem-detector-${npd_version}.tar.gz" </del> <ins> local -r npd_tar="node-problem-detector-${npd_version}-${HOST_PLATFORM}_${HOST_ARCH}.tar.gz" </ins> if is-preloaded "${npd_tar}" "${npd_hash}"; then echo "${npd_tar} is preloaded."

cpu: {{hollow_proxy_millicpu}}m memory: {{hollow_proxy_mem_Ki}}Ki - name: hollow-node-problem-detector <del> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.7 </del> <ins> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.8 </ins> env: - name: NODE_NAME valueFrom:
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 --Exclude node from LoadBalancer (via kubectl label node node1) leads to failing reconciliation of the existing load balancer services in the cluster with following error: The legacy provider azure is not using an AvailablilitySet as it it running with those cloudprovider config: Creating new load balancer services have the effect that they are stuck in due to same issue. Service reconciliation should succeed. Create an Azure k8s cluster with with an Azure cloud controller manager based on legacy-cloud-provider azure in the corresponding k8s version Configure the cloud controller manager to use the feature gate Create a service of type LoadBalancer in the cluster and wait until it was created Label a node with Check the cloud-controller-manager logs New load balancer services will now stuck in Pending state Maybe related to but should be fixed with Kubernetes version (use ): Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure cc
/assign
/triage accepted
/assign
, thanks for the fix. Can you also create a cherry-pick to kubernetes/kubernetes
we hit a similar issue in in-tree provider as well, could you please help cherry-pick the fix to 1.20 and later release? Thanks.
Here are the cherry-picks to k/k:

Discussion:
"net/http" "github.com/GoogleCloudPlatform/kubernetes/pkg/health" <ins> "github.com/golang/glog" </ins> ) type HealthyMinionRegistry struct {

for _, minion := range list { status, err := health.Check(h.makeMinionURL(minion), h.client) if err != nil { <del> return result, err </del> <ins> glog.Errorf("%s failed health check with error: %s", minion, err) continue </ins> } if status == health.Healthy { result = append(result, minion)
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --https://k8s- kubeadm-init 06-22 https://k8s- all kubeadm jobs are failing against k/k master. is this failing after we merged?
cc /sig cluster-lifecycle /area kubeadm kinder cluster preparation constructs images locally by downloading tarballs and tagging them with: then running it would find the image locally and not pull it from GCR. does not contain pre-release images, so trying to pull these images would fail. i think the problem here is that we broke the default behavior with
ok, the problem is indeed here: empty string "" should be the same as PullIfNotPresent.
should be fixed by
/triage accepted

Discussion:
// Check pulls images required by kubeadm. This is a mutating check func (ipc ImagePullCheck) Check() (warnings, errorList []error) { <ins> policy := ipc.imagePullPolicy if len(policy) == 0 { policy = v1.PullIfNotPresent // Default behavior if the policy is unset } klog.V(1).Infof("using image pull policy: %s", policy) </ins> for _, image := range ipc.imageList { <del> switch ipc.imagePullPolicy { </del> <ins> switch policy { </ins> case v1.PullNever: <ins> klog.V(1).Infof("skipping pull of image: %s", image) </ins> continue case v1.PullIfNotPresent: ret, err := ipc.runtime.ImageExists(image)

if err != nil { errorList = append(errorList, errors.Wrapf(err, "failed to check if image %s exists", image)) } <del> } klog.V(1).Infof("pulling %s", image) if err := ipc.runtime.PullImage(image); err != nil { errorList = append(errorList, errors.Wrapf(err, "failed to pull image %s", image)) </del> <ins> fallthrough // Proceed with pulling the image if it does not exist case v1.PullAlways: klog.V(1).Infof("pulling: %s", image) if err := ipc.runtime.PullImage(image); err != nil { errorList = append(errorList, errors.Wrapf(err, "failed to pull image %s", image)) } default: // If the policy is unknown return early with an error errorList = append(errorList, errors.Errorf("unsupported pull policy %q", policy)) return warnings, errorList </ins> } } return warnings, errorList

"net/http" "os" <del> v1 "k8s.io/api/core/v1" </del> "k8s.io/apimachinery/pkg/util/sets" kubeadmapi "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm" "k8s.io/kubernetes/cmd/kubeadm/app/constants"

check := ImagePullCheck{ runtime:         containerRuntime, imageList:       []string{"img1", "img2", "img3"}, <del> imagePullPolicy: v1.PullIfNotPresent, </del> <ins> imagePullPolicy: "", // should be defaulted to v1.PullIfNotPresent </ins> } warnings, errors := check.Check() if len(warnings) != 0 {
Change:
Using a CSI volume on a Linux machine with SELinux in enforcing mode. I noticed when the volume is used in a pod and the first NodePublishVolume for that pod fails (e.g. timeout), the volume does not get correct SELinux labels. The volume gets correct SELinux labels. With a hacked CSI driver that returns error on the first NodePublishVolume. a pod with a CSI volume. the first NodePublishVolume fails (e.g. DeadlineExceeded). that a subsequent NodePublishVolume succeeds. the pod is Running. SELinux label of the volume Got , where was expected. Kubernetes version (use ): 1.20.something Cloud provider or hardware configuration: N/A OS (e.g: ): "Red Hat Enterprise Linux CoreOS 47.83.-0 (Ootpa)"
This breaks applications on clusters with CSI drivers that tend to time out with the first NodePublishVolume - the pods can't access their data and they get instead. /priority important-soon /sig storage /triage accepted
Root cause: VolumeManager's ActualStateOfWorld (ASW) uses a wrong when a volume gets mounted. volume plugin stores a flag if a volume supports SELinux after NodePublish succeeds: the first NodePublish does not succeed, of the stays . This first is used as interface when marking the volume as uncertain in ASW / : is called again. It succeeds and is set correctly to , however, it's a different than the one saved in ASW. The Mounter is ASW is not updated at this point. calls on the from step 2., which returns and the volume is not relabeled.
There are several ways out of this. For example, operation generator should use the same Mounter all the time, even in subsequent attempts. IMO the best would be to modify to update on every call.
Another idea: we could move detection of SELinux on a volume into call. This way, we would not need to pass a flag in around. But the detection can fail with an error and can't return one (at least today).
Implemented this approach in

Discussion:
// If pod exists, reset remountRequired value podObj.remountRequired = false podObj.volumeMountStateForPod = markVolumeOpts.VolumeMountState <ins> if mounter != nil { // The mounter stored in the object may have old information, // use the newest one. podObj.mounter = mounter } </ins> asw.attachedVolumes[volumeName].mountedPods[podName] = podObj return nil }
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 --Hello, Found a potential data race in testing. There is a test If we update it like this (we actually can do it ): If watcher updates received object we get a data race. No data race My suggestion: send copy of object here:
/sig api-machinery
/cc /triage accepted Do you remember if we fixed similar issues before?
Hi ,The code avoiding data race seems to already exist If you commented the code on above, the following test case will pass (because of data race), so I think there is no data race in the code : )
Hi Did you run my test with flag? Of course if I comment there will be data race. But let's take a look at: We store in and do with the same . So, watcher receives that is stored in map. we call we take the same from : Therefore, if watcher modifies received in another goroutine we have data race. Output:
Hi You're right ,thank you for solving my confusion. One solution could be to copy of , I will try to fix it.

Discussion:
if _, ok = t.objects[gvr][namespacedName]; ok { if replaceExisting { for _, w := range t.getWatches(gvr, ns) { <del> w.Modify(obj) </del> <ins> // To avoid the object from being accidentally modified by watcher w.Modify(obj.DeepCopyObject()) </ins> } t.objects[gvr][namespacedName] = obj return nil

t.objects[gvr][namespacedName] = obj for _, w := range t.getWatches(gvr, ns) { <del> w.Add(obj) </del> <ins> // To avoid the object from being accidentally modified by watcher w.Add(obj.DeepCopyObject()) </ins> } return nil

delete(objs, namespacedName) for _, w := range t.getWatches(gvr, ns) { <del> w.Delete(obj) </del> <ins> w.Delete(obj.DeepCopyObject()) </ins> } return nil }
Change:
Address the TODO here:
I'm interested in knocking this out, but am not entirely sure where this would be propagated. Seems related to / ?

Discussion:
appsv1 "k8s.io/api/apps/v1" batchv1 "k8s.io/api/batch/v1" corev1 "k8s.io/api/core/v1" <ins> apierrors "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apiserver/pkg/admission"

audit.AddAuditAnnotation(ctx, podsecurityadmissionapi.AuditAnnotationPrefix+k, v) } if !result.Allowed { <del> if result.Result != nil && len(result.Result.Message) > 0 { // TODO: use code/reason/etc from status return admission.NewForbidden(a, errors.New(result.Result.Message)) </del> <ins> // start with a generic forbidden error retval := admission.NewForbidden(a, errors.New("Not allowed by PodSecurity")).(*apierrors.StatusError) // use message/reason/details/code from admission library if populated if result.Result != nil { if len(result.Result.Message) > 0 { retval.ErrStatus.Message = result.Result.Message } if len(result.Result.Reason) > 0 { retval.ErrStatus.Reason = result.Result.Reason } if result.Result.Details != nil { retval.ErrStatus.Details = result.Result.Details } if result.Result.Code != 0 { retval.ErrStatus.Code = result.Result.Code } </ins> } <del> return admission.NewForbidden(a, errors.New("Not allowed by PodSecurity")) </del> <ins> return retval </ins> } return nil }