jiebi/CodeConvo huggingface dataset:
Change:
// if usage shows no change, just return since it has no impact on quota deltaUsage := evaluator.Usage(inputObject) if admission.Update == op { <del> prevItem, err := evaluator.Get(namespace, name) if err != nil { return nil, admission.NewForbidden(a, fmt.Errorf("Unable to get previous: %v", err)) </del> <ins> prevItem := a.GetOldObject() if prevItem == nil { return nil, admission.NewForbidden(a, fmt.Errorf("Unable to get previous usage since prior version of object was not found")) </ins> } prevUsage := evaluator.Usage(prevItem) deltaUsage = quota.Subtract(deltaUsage, prevUsage)

Discussion:
the ability to get the previous version of an object directly via admission control. As a result, admission code can now use this rather than fetching the object directly. Need to update:
/cc - this is a necessary follow-up, will get to it soon.
Change:
- group: root - mode: 755 <ins> /var/lib/kubelet/pki: file.directory: - mode: 755 - makedirs: True </ins> # The default here is that this file is blank. If this is the case, the kubelet # won't be able to parse it as JSON and it will not be able to publish events # to the apiserver. You'll see a single error line in the kubelet start up file

Discussion:
https://k8s- Judging by the timestamp, it's this batch of merge caused the failure: NONE
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
looks like it's your pr causing the failure ^^^
cc
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
It's still failing, See build log: https://k8s-, kubelet log: error in kubelet log:
Change:
command := exec.Command("umount", target) output, err := command.CombinedOutput() if err != nil { <del> if err.Error() == errNoChildProcesses { if command.ProcessState.Success() { // We don't consider errNoChildProcesses an error if the process itself succeeded (see - k/k issue #103753). return nil } // Rewrite err with the actual exit error of the process. err = &exec.ExitError{ProcessState: command.ProcessState} } if mounter.withSafeNotMountedBehavior && strings.Contains(string(output), errNotMounted) { klog.V(4).Infof("ignoring 'not mounted' error for %s", target) return nil } return fmt.Errorf("unmount failed: %vnUnmounting arguments: %snOutput: %s", err, target, string(output)) </del> <ins> return checkUmountError(target, command, output, err, mounter.withSafeNotMountedBehavior) </ins> } return nil }

Discussion:
A status of Pod mounted NFS PV remain as terminating when a node shutdown and restart. A Pod is completely terminated. Deploy a Pod mounted NFS PV Shutdown the node where the Pod is running Wait for 5 min and the Pod status become Restart the node The Pod status is still and the Pod is never terminated completely <detailsPrepare a NFS Server.(I used ) Deploy a Pod mounted NFS PV like this. Shutdown the node where the Pod is running.(In this case ) And the status of node02 becomes . After 5 min later(by default), the Pod status becomes . (The time a Pod becomes status depends on .) Then, restart the node and the status of node02 becomes . But the Pod status is still and the Pod is never terminated completely. It seems that a faild to delete Pod because of trying to unmount a not mounted directory. Force delete Pod. Delete Pod's directory on the node. </detailsNo response <details</details<detailsnone(on premise) </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
/sig node
It dose not happen using , so it seems to depend on NFS volume plugin.
/assign
I try to build and run kubelet with comment out this logic. Then it seems to get well. related: This change checks the result of instead of the mount point check. However, check logic is not implemented in and (these functions are used in NFS volume plugin), despite it is done in .
/remove-sig node /sig storage
Reopening, fix had to be reverted due to unit tests requiring root permissions ()
I am terribly sorry... Please wait a moment. I'll try to fix it.
no worries, just get to review the rework, making sure the units tests don't require root permissions
Thank you! Fixed in .
Are there any plans to backport this to older Kubernetes versions? This seems like a critical fix.
Change:
provisioner: kubernetes.io/gce-pd parameters: type: pd-standard <ins> allowVolumeExpansion: true </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Enable it in the default storageclass. Why is this needed: Since resizing behavior has to be triggered by user action, I don't see a reason why we shouldn't allow it by default. /assign
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
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
/remove-lifecycle stale
Change:
echo "${KUBE_VERSION}" else echo "Using version at ${1}: ${KUBE_VERSION}" >&2 <del> tars_from_version curl --fail -o kubernetes-${KUBE_VERSION}.tar.gz "${KUBE_TAR_URL}" </del> <ins> if [[ ${KUBE_VERSION} =~ ${KUBE_VERSION_REGEX} ]]; then curl --fail -o kubernetes-${KUBE_VERSION}.tar.gz "https://storage.googleapis.com/kubernetes-release/release/${KUBE_VERSION}/kubernetes.tar.gz" elif [[ ${KUBE_VERSION} =~ ${KUBE_CI_VERSION_REGEX} ]]; then curl --fail -o kubernetes-${KUBE_VERSION}.tar.gz "https://storage.googleapis.com/kubernetes-release/ci/${KUBE_VERSION}/kubernetes.tar.gz" else echo "Version doesn't match regexp" >&2 exit 1 fi </ins> fi

Discussion:
I suspect we're going through an if/else clause where KUBETARURL isn't defined, and not defaulting it, though the function header seems to indicate it should be set in the callee.
Will take a look.
Is this in Jenkins, or on a local run? The Jenkins push job is borked as well, but it looks like it's for a different reason: Which I'm taking care of in .
Jobs are generating incredibly large log files (300 Megs?) with lots of repeated lines like this: Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 I think this needs to be resolved, since it already caused an out-of-disk in Jenkins.
Okiedokie. Yes, this was my fault. silently expects and to be set in . I the extra expectation that be set, but didn't think about how would then also have to set that. Working on a fix.
(For anyone who cares, culprit is .)
Change:
RUN apt-get -q update &&  apt-get install -y dnsutils &&  apt-get clean <ins> ADD https://github.com/coredns/coredns/releases/download/v1.5.0/coredns_1.5.0_linux_BASEARCH.tgz /coredns.tgz RUN tar -xzvf /coredns.tgz && rm -f /coredns.tgz </ins>

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: should support configurable pod Since when has it been failing: N/A Testgrid link: N/A Reason for failure: Since ` was used instead. Anything else we need to know: /sig testing /sig windows
Change:
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 

Discussion:
<!-- 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
Change:
# Set up the context directory for the kube-build image and build it. function kube::build::build_image() { mkdir -p "${LOCAL_OUTPUT_BUILD_CONTEXT}" <ins> # Make sure the context directory owned by the right user for syncing sources to container. chown -R ${USER_ID}.${GROUP_ID} "${LOCAL_OUTPUT_BUILD_CONTEXT}" </ins> cp /etc/localtime "${LOCAL_OUTPUT_BUILD_CONTEXT}/"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one):BUG REPORT Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2850+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-06T09:06:04Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2753+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-04T08:46:56Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} What happened: How to reproduce it (as minimally and precisely as possible): the owner of file is not right
Do you need to be building as root?
I get an annoying message when building as normal user: So I run as root. There will return a error if the outpt build directory is not owned by root when running as root. I think we could use to fix it.
I hope to get some of your suggestions
did you previously build as ? you might need to before a build as a normal user works again.
Change:
repeated NetworkPolicyEgressRule egress = 3; // List of rule types that the NetworkPolicy relates to. <del> // Valid options are Ingress, Egress, or Ingress,Egress. </del> <ins> // Valid options are "Ingress", "Egress", or "Ingress,Egress". </ins> // If this field is not specified, it will default based on the existence of Ingress or Egress rules; // policies that contain an Egress section are assumed to affect Egress, and all policies // (whether or not they contain an Ingress section) are assumed to affect Ingress.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: bug report /kind bug What happened: I was reading the documentation for as defined What you expected to happen: To have clear documentation How to reproduce it (as minimally and precisely as possible): Read the following, as seen in the 1.12 docs: Anything else we need to know?: Nope Environment: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
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
Is it a case whereby only can be specified as , or only , or both (note the ) ? If that's the case, do you think the following would make it clearer?
It is confusing to have commas used for English grammar and array element delineation in the same sentence. What about simply this?
sounds like a great fix! Putting out a quick pr with this change now :)
Change:
func TestValidatePodSpec(t *testing.T) { activeDeadlineSeconds := int64(30) <ins> minID := int64(0) maxID := int64(2147483647) </ins> successCases := []api.PodSpec{ { // Populate basic fields, leave defaults for most. Volumes:       []api.Volume{{Name: "vol", VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{}}}},

Discussion:
Help review this, thanks.
Are you asking for better validation on pod creation? I'm not really sure what you mean when you say "tip".
Yes, I mean it's better validate the pod when create. The tip mean the validation info response from server and show by client.
Change:
"format": "int32" }, "revisionHistoryLimit": { <del> "description": "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 2.", </del> <ins> "description": "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10.", </ins> "type": "integer", "format": "int32" },

Discussion:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps
Change:
return e } <ins> func podContainerFailed(c clientset.Interface, namespace, podName string, containerIndex int, reason string) wait.ConditionFunc { return func() (bool, error) { pod, err := c.CoreV1().Pods(namespace).Get(context.TODO(), podName, metav1.GetOptions{}) if err != nil { return false, err } switch pod.Status.Phase { case v1.PodPending: if len(pod.Status.ContainerStatuses) == 0 { return false, nil } containerStatus := pod.Status.ContainerStatuses[containerIndex] if containerStatus.State.Waiting != nil && containerStatus.State.Waiting.Reason == reason { return true, nil } return false, nil case v1.PodFailed, v1.PodRunning, v1.PodSucceeded: return false, fmt.Errorf("pod was expected to be pending, but it is in the state: %s", pod.Status.Phase) } return false, nil } } </ins> // LogPodStates logs basic info of provided pods for debugging. func LogPodStates(pods []v1.Pod) { // Find maximum widths for pod, node, and phase strings for column printing.

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: N/A Which test(s) are failing: should fail substituting values in a volume subpath with absolute path Since when has it been failing: N/A Testgrid link: N/A Reason for failure: Some of the tests are negative test cases which are supposed to ensure that those invalid usecases are handled properly. However, some of the tests are false positives, they can pass due to various reasons. One such example is: should fail substituting values in a volume subpath with absolute path. This test can pass if: the Pod cannot start due to various reasons (e.g.: the container image cannot be pulled or does not exist). the Pod ran to completion, even though the container was not supposed to start in the first place. Anything else we need to know: /sig testing Related:
/sig storage SIG storage owns the test case, though I see that you are changing core framework methods to fix this, so leaving SIG testing. Looks like also possibly sig-node, skimming the linked PRs Based on the PRs this also appears to be related to windows? (unsure, no mention here)
I've Related: to the issue description. After fixing this test, I've noticed that it now fails on Windows, which means the issue was masked by the test's false positive result. Basically, it means that you can have volume subpaths with absolute paths substituted on variable expansion and have Windows containers use them and be running, which according to the test, it shouldn't be a supported usecase. The fix should probably be also backported to previous releases.
Change:
# Path for kube-proxy kubeconfig file on Windows nodes. export WINDOWS_KUBEPROXY_KUBECONFIG_FILE="${WINDOWS_K8S_DIR}kubeproxy.kubeconfig" # Pause container image for Windows container. <del> export WINDOWS_INFRA_CONTAINER="gcr.io/gke-release/pause-win:1.2.1" </del> <ins> export WINDOWS_INFRA_CONTAINER="gcr.io/gke-release/pause-win:1.5.1" </ins> # Storage Path for csi-proxy. csi-proxy only needs to be installed for Windows. export CSI_PROXY_STORAGE_PATH="https://storage.googleapis.com/gke-release/csi-proxy" # Version for csi-proxy

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add Support for Windows Server version 2004 and 20H2. Why is this needed: Windows Server version 1909 is going end of life.
/sig windows /triage accepted
Change:
echo "    echo 'Waiting for metadata MINION_IP_RANGE...'" echo "    sleep 3" echo "done" <ins> echo "" echo "# Remove docker artifacts on minion nodes" echo "iptables -t nat -F" echo "ifconfig docker0 down" echo "brctl delbr docker0" echo "" </ins> echo "EXTRA_DOCKER_OPTS='${EXTRA_DOCKER_OPTS}'" echo "ENABLE_DOCKER_REGISTRY_CACHE='${ENABLE_DOCKER_REGISTRY_CACHE:-false}'" grep -v "^#" "${KUBE_ROOT}/cluster/gce/templates/common.sh"

Discussion:
I suspect this is dues to the recent change to container VMs as the base image? ifconfig docker0 - exists but should not. iptables-save | grep docker - 4 docker rules that should not exist.
Is this still relevant?
was still a containervm turd the last time I checked. It's just not causing any harm.
Yeah, no harm, just ugly. , Zach Loafman wrote:
I think we should remove the docker0 from minion nodes, but do we still need this for master node? cc/
This is required by running etcd server as pod with flannel on gce nodes. Please sync your cluster with this fix.
Change:
"failFSGroupOutOfRange": { pod:           failFSGroupPod, psp:           failFSGroupPSP, <del> expectedError: "999 is not an allowed group", </del> <ins> expectedError: "group 999 must be in the ranges: [{1 1}]", </ins> }, "failFSGroupEmpty": { pod:           defaultPod(),

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: This is request for improvements. What happened: When PodSecurityPolicy provider validates or fields of a pod, it shows an error like "999 is not an allowed group" if the group doesn't belong to the range(s). What you expected to happen: It should include to the error message also the allowed values -- the ranges against what we were validating this group. This will simplify user experience and debugging. How to reproduce it (as minimally and precisely as possible): run kubernetes cluster with PSP support create a PSP that allows fsGroup/SupplementalGroups in some ranges grant to a user access to this PSP try to create a pod that has fsGroup/SupplementalGroups outside of the allowed ranges Anything else we need to know?: In order to improve the current behavior, we need to modify function here: Reported-by: /kind help
This looks like a good first issue! My suggestion would be something like . I would also suggest to merge overlaying ranges in the log message, like as , to keep the log as concise as possible. I will look into it.
Maybe something like ? Thank you!
We can use the same approach that strategy uses:
Sure, that is probably the most consistent solution.
/remove-help
Change:
&api.Pod{ DesiredState: desiredState, CurrentState: api.PodState{ <ins> Host: "machine-2", }, }, api.PodTerminated, "no info, but bad machine", }, { &api.Pod{ DesiredState: desiredState, CurrentState: api.PodState{ </ins> Info: map[string]docker.Container{ "containerA": runningState, "containerB": runningState,

Discussion:
to reproduce: create vagrant kubernetes with 5 minions. try guest book example on it. After provisioning: then kill 10.245.2.6 minion: then we get: Nothing changes even after waiting for significant period of time. Please note, that while redis-master wasn't in replication controller and it's not expected for it to restart, it's still wrongfully marked as Running.
Change:
// Enables kubelet to detect CSI volume condition and send the event of the abnormal volume to the corresponding pod that is using it. CSIVolumeHealth featuregate.Feature = "CSIVolumeHealth" <del> // owner: @enj // beta: v1.22 // ga: v1.24 // // Allows clients to request a duration for certificates issued via the Kubernetes CSR API. CSRDuration featuregate.Feature = "CSRDuration" </del> // owner: @adrianreber // kep: http://kep.k8s.io/2008 // alpha: v1.25

Discussion:
Remove the "CSRDuration" feature gate starting in Kube v1.26. PR proposes that the CertificateSigningRequest's Spec.ExpirationSeconds field be promoted to GA in v1.24. It was originally introduced as beta in v1.22 with a corresponding feature gate called "CSRDuration" to optionally disable it (see PR ). If PR is merged and included in v1.24, then in v1.26 the "CSRDuration" feature gate should be removed. See also where a member of SIG-auth asked me to create this issue.
/sig auth
/triage accepted /milestone v1.26
Is this task a ? I would like to be assign to it.
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]:
/remove-lifecycle stale
I'd like to work on this! /assign
Fixed it here: