jiebi/CodeConvo huggingface dataset:
Change:
"metadata": { %s "name": "subobject", <del> "namespace": "my-ns" </del> <ins> "namespace": "%s" </ins> } } } }` meta := unknownFieldMetadataJSON(gvk, "test-cr") <del> unknownRootMetaCR := fmt.Sprintf(embeddedCRPattern, meta, "") </del> <ins> unknownRootMetaCR := fmt.Sprintf(embeddedCRPattern, meta, "", ns) </ins> _, err = framework.RunKubectlInput(ns, unknownRootMetaCR, "create", "--validate=true", "-f", "-") if err == nil { framework.Failf("unexpected nil error when creating CR with unknown root metadata field")

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig cli
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
/assign

/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig cli
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
/assign
Change:
Corefile: | .:53 { errors <del> log stdout </del> <ins> log </ins> health kubernetes {{ .DNSDomain }} {{ .ServiceCIDR }} { pods insecure

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG What happened: When CoreDNS is deployed by default using feature-gates of kubeadm, it does not log anything when processing a DNS query. That is due to change of log option of CoreDNS in latest version. that version was bumped up in kubeadm, but the manifest was not adapted to the new log option. initial change of 'log stdout' in CoreDNS : version of CoreDNS 1.0.0 bumped into Kubeadm : NOTE: I guess we should also changed manifests for kube-up : see The change in manifest expected is to remove the option "stdout" in the line "log ...". As it is now interpreted as a scope of domain to log. Invalid manifest: Environment: Kubernetes version (use ): 1.9 and MAIN Cloud provider or hardware configuration: any Install tools: kubeadm, kube-up the configmap for coredns kubectl get configmaps -n kube-system coredns -o yaml kubectl replace -f - the coredns deployment kubectl scale deployment --replicas=0 -n kube-system coredns kubectl scale deployment --replicas=1 -n kube-system coredns
/cc /sig network
NOTE: only log is impacted. CoreDNS working as expected.
/cc
I have a question : the initial manifest is done for the image 0.9.10 of CoreDNS. Bumping the version of CoreDNS was done by changing the version in file (see ) which means that the image's version is STILL 0.9.10 in the manifests ... and the corefile config is correct against the version of the manifest. QUESTION: when modifying the , is there a way to upgrade the manifest by program ? I guess at the time the new version number is applied on the manifest ...
thanks for reporting this! I send PR to update the Corefile. I don't think of a way so far. I guess we can't unless there is a way to get the Corefile from some place of upstream (CoreDNS).
Change:
ns := f.Namespace n.externalPluginName = fmt.Sprintf("example.com/nfs-%s", ns.Name) <del> // Reset config. It might have been modified by a previous CreateVolume call. n.driverInfo.Config.ServerConfig = nil </del> // TODO(mkimuram): cluster-admin gives too much right but system:persistent-volume-provisioner // is not enough. We should create new clusterrole for testing. framework.BindClusterRole(cs.RbacV1beta1(), "cluster-admin", ns.Name,

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce/gke multizone/regional jobs Which test(s) are failing: Only PD tests Since when has it been failing: Around 12/21 with the 16:49 run Testgrid link: https://k8s- Reason for failure: TBD Anything else we need to know: <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
The runs started flaking after merged. cc Here's one failing run: Pod pod-subpath-test-gcepd-dynamicpv-pfsm failed to schedule because of conflicting node selectors: We shouldn't need to set the node selector for PD tests using PVs.
The PR broke the subpath test because the modification to the config struct embedded in the driver info now persists across tests: A quick fix would be to reset that field in CreateDriver. The long-term fix is the change discussed in My preference is to do the quick fix now, then either merge or close PRs in this order: (needs a decision about logging of tests that aren't getting defined, see ) a future PR for What I'd like to avoid is having to rebase PR on top of the long-term solution for issue - that'll be lots of code conflicts.
/assign PR is here: PR
Change:
# exit on any error set -e <ins> gsutil_version=$(gsutil version | awk '{split($0,a," "); print a[3]}') # Warning! uses lexical comparison.  This really only works for major versions, or minor versions up to x.9 min_gsutil_version="4.0" if [[ "$gsutil_version" < "$min_gsutil_version" ]]; then echo "gsutil version $min_gsutil_version or greater is required, please run 'gcloud components upgrade'" exit 1 fi </ins> SCRIPT_DIR=$(CDPATH="" cd $(dirname $0); pwd) source $SCRIPT_DIR/config.sh

Discussion:
As I discovered the hard way, if the json GCS api is not turned on for a project, will not surface this error, but just loop 'forever'. API access errors should be easy to catch, so it would be great to surface them on cluster startup and abort with a useful message. (I might take a look at this).
This is described in step 3 of But I agree that it would be better if the tool could catch this case and let the user know (it bit me the first time I tried to run that script as well).
Change:
return "localhost/" + seccompLocalhostRef(profileName) } <ins> func TestIsInitContainerFailed(t *testing.T) { tests := []struct { status      *kubecontainer.Status isFailed    bool description string }{ { status: &kubecontainer.Status{ State:    kubecontainer.ContainerStateExited, ExitCode: 1, }, isFailed:    true, description: "Init container in exited state and non-zero exit code should return true", }, { status: &kubecontainer.Status{ State: kubecontainer.ContainerStateUnknown, }, isFailed:    true, description: "Init container in unknown state should return true", }, { status: &kubecontainer.Status{ Reason:   "OOMKilled", ExitCode: 0, }, isFailed:    true, description: "Init container which reason is OOMKilled should return true", }, { status: &kubecontainer.Status{ State:    kubecontainer.ContainerStateExited, ExitCode: 0, }, isFailed:    false, description: "Init container in exited state and zero exit code should return false", }, { status: &kubecontainer.Status{ State: kubecontainer.ContainerStateRunning, }, isFailed:    false, description: "Init container in running state should return false", }, { status: &kubecontainer.Status{ State: kubecontainer.ContainerStateCreated, }, isFailed:    false, description: "Init container in created state should return false", }, } for i, test := range tests { isFailed := isInitContainerFailed(test.status) assert.Equal(t, test.isFailed, isFailed, "TestCase[%d]: %s", i, test.description) } } </ins> func TestStableKey(t *testing.T) { container := &v1.Container{ Name:  "test_container",

Discussion:
Init container exited with OOMKilled reason, but init container was marked succesful, and main app container was allowed to be started If non init process gets killed the container should not be marked OOMKilled or If OOMKilled is terminate reason main app contaienr should not be started. According to Container should only be marked OOMKilled if init process is killed. the container the When checking init container status: But main app container is running. Kubernetes version (use ): Dockerfile:
According to previous issue will add sig label: /sig node
/assign
I have a quesion. when the oom killer, why your init container exit code is 0. normal is 137.
the init process is the shell script. the oom killer kills the forked process of stress tester, and it continues the script. next step is to exit 0 in the if process. wth error handling this can be caught, but my problem is, if there is a 0 exit code, and init process isnt oom killed, why is there a reason of oomkilled.
when you use shell scripts, you should add . kubelet will collect the status of init container. when init container is oomkilled, the container status will save the oom kill message.
I understand that. but according to the behaviour that is written, this is not expected outcome. The init container was not killed because of oom, just a single process. There should be 2 expected behaviours: Either there should be no printed, since it should only be when the main init process gets killed Or the whole init container should fail if any process is caught with oom.
I think you are right.
/assign
/triage accepted
Change:
// if we got a default namespace, determine whether it was explicit or implicit if raw, err := mergedKubeConfig.RawConfig(); err == nil { <del> if context := raw.Contexts[raw.CurrentContext]; context != nil && len(context.Namespace) > 0 { </del> <ins> // determine the current context currentContext := raw.CurrentContext if config.overrides != nil && len(config.overrides.CurrentContext) > 0 { currentContext = config.overrides.CurrentContext } if context := raw.Contexts[currentContext]; context != nil && len(context.Namespace) > 0 { </ins> return ns, false, nil } }

Discussion:
<!-- 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!--What happened: In-cluster namespace isn't overridden by kubeconfig if the context is specified via kubectl flag. When using , the override works as expected. What you expected to happen: If I specify for a context in kubeconfig, then I expect to use as the default namespace, regardless of whatever's in . How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: supposedly fixed this issue, but not for the case where the context is specified via a command line flag (). This is because this line checks for . Environment: Kubernetes version (use ): v1.10.5 (details above) Cloud provider or hardware configuration: - OS (e.g. from /etc/os-release): - Kernel (e.g. ): - Install tools: - Others: - <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
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
fixed in
Change:
for _, node := range nodeList.Items { n := node <ins> wg.Add(1) </ins> go func() { nodeUUID := getUUIDFromProviderID(n.Spec.ProviderID) framework.Logf("Searching for node with UUID: %s", nodeUUID)

Discussion:
Command run: vSphere intree volume test suite occasionally failed with the following error: The test suite should always pass. We may have a chance to hit this by running ` No response binary version: 1.27.4 </details<detailsvsphere </details<details</details<details</details<details</details<details</details
/assign
/sig testing storage ?
/triage accepted
Change:
} m.recordContainerEvent(pod, containerSpec, containerID.ID, v1.EventTypeNormal, events.KillingContainer, message) <ins> if gracePeriodOverride != nil { gracePeriod = *gracePeriodOverride klog.V(3).InfoS("Killing container with a grace period override", "pod", klog.KObj(pod), "podUID", pod.UID, "containerName", containerName, "containerID", containerID.String(), "gracePeriod", gracePeriod) } </ins> // Run the pre-stop lifecycle hooks if applicable and if there is enough time to run it if containerSpec.Lifecycle != nil && containerSpec.Lifecycle.PreStop != nil && gracePeriod > 0 { gracePeriod = gracePeriod - m.executePreStopHook(ctx, pod, containerID, containerSpec, gracePeriod) } // always give containers a minimal shutdown window to avoid unnecessary SIGKILLs if gracePeriod < minimumGracePeriodInSeconds { gracePeriod = minimumGracePeriodInSeconds } <del> if gracePeriodOverride != nil { gracePeriod = *gracePeriodOverride klog.V(3).InfoS("Killing container with a grace period override", "pod", klog.KObj(pod), "podUID", pod.UID, "containerName", containerName, "containerID", containerID.String(), "gracePeriod", gracePeriod) } </del> klog.V(2).InfoS("Killing container with a grace period", "pod", klog.KObj(pod), "podUID", pod.UID, "containerName", containerName, "containerID", containerID.String(), "gracePeriod", gracePeriod)

Discussion:
Termination grace period includes the termination time of prestop hooks and containers in the pod. The total time that the pod terminates should always be < termination grace period seconds. A misconfigured pod with a preStopHook that hangs indefinitely and pod ignoring SIGTERM can result in the pod taking 2X (double) the termination grace period seconds to terminate. The time to terminate the pod should always be <= termination grace period seconds including prestop hook execution time as documented in 1) Apply the following pod 2) 3) Observe it actually took ~120s to terminate the pod not ~60s as would be expected. The kubelet logs for the pod The issue is that we are not taking into account the time taken by execution of the prestop hook when calculating the time remaining to kill the remaining containers in the pod. Reproduced on 1.26.0 <detailsn/a </details<details</details<details</details<details</details<details</details
/sig node
/sig node
The same error occurs in my local cluster, if you don't mind, I'd be happy to help fix the bug.
/assign
/triage accepted /priority important-longterm (I assume it is not a regression)
Change:
filepath.Join("pod2uid", "volumes", "fake-plugin", "volume-name"), }, createMountPoint: true, <del> podInfos:         []podInfo{defaultPodInfo}, </del> <ins> podInfos: []podInfo{ { podName:         "pod2", podUID:          "pod2uid", outerVolumeName: "volume-name", innerVolumeName: "volume-name", }, }, </ins> verifyFunc: func(rcInstance *reconciler, fakePlugin *volumetesting.FakeVolumePlugin) error { // for pod that is deleted, volume is considered as mounted mountedPods := rcInstance.actualStateOfWorld.GetMountedVolumes() if len(mountedPods) != 1 { return fmt.Errorf("expected 1 pods to in asw got %d", len(mountedPods)) } <del> if types.UniquePodName("pod2uid") != mountedPods[0].PodName { return fmt.Errorf("expected mounted pod to be %s got %s", "pod2uid", mountedPods[0].PodName) </del> <ins> if types.UniquePodName("pod1uid") != mountedPods[0].PodName { return fmt.Errorf("expected mounted pod to be %s got %s", "pod1uid", mountedPods[0].PodName) } // for pod that is in dsw, volume is in skippedDuringReconstruction skippedVolumes := rcInstance.skippedDuringReconstruction if len(skippedVolumes) != 1 { return fmt.Errorf("expected 1 pods to in skippedDuringReconstruction got %d", len(skippedVolumes)) } if skippedVolumes["fake-plugin/volume-name"] == nil { return fmt.Errorf("expected %s is in skippedDuringReconstruction, got %+v", "fake-plugin/volume-name", skippedVolumes) </ins> } return nil },

Discussion:
This issue is very similar to , they have the same symptom: remote volumes of the pods are becoming local mount point after rebooting the Node. And this issue is triggered by The difference is that in , kubelet didn't call , so the global mount point is local, but it will still call for the pod to bind mount the pod volume to the global mount point. Whereas in this issue, kubelet neither call globally nor call for the pod. This is more harmful: After writing some data to the pod volume, pod can't be deleted because kubelet encounter error while unmounting the pod volume: ! Reproduce steps: a cluster with one Node a deployment with two replicas(say and ) using Non-attachable volume (for example Azurefile) the Node with option (Use force deletion to simulate the situation that mount point was left over before rebooting the Node.) back the Node is always in Running state, however, after rebooting, it won't call and the volume it uses is local volume. should call . As mentioned above. No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
Clusters with enabled is not impacted.
/sig node storage (for triage)
/remove-sig node sig-storage please triage this first. Thanks
/triage accepted
Change:
podClient.Delete(context.Background(), podName, metav1.DeleteOptions{}) // Wait for pod to go unready <del> err = wait.PollImmediate(framework.Poll, f.Timeouts.PodDelete, func() (bool, error) { pod, err := podClient.Get(context.Background(), podName, metav1.GetOptions{}) if err != nil { return false, err </del> <ins> err = waitForPodStatusByInformer(f.ClientSet, f.Namespace.Name, podName, f.Timeouts.PodDelete, func(pod *v1.Pod) (bool, error) { if !podutil.IsPodReady(pod) { return true, nil </ins> } <del> // verify the pod ready status has reported not ready return !podutil.IsPodReady(pod), nil </del> <ins> framework.Logf("pod %s/%s is still ready, waiting until is not ready", pod.Namespace, pod.Name) return false, nil </ins> }) framework.ExpectNoError(err)

Discussion:
pull-kubernetes-e2e-kind-ipv6 Kubernetes e2e suite.[It] [sig-node] Probing container should mark readiness on pods to false and disable liveness probes while pod is in progress of terminating See also, possibly related: Kubernetes e2e suite.[It] [sig-node] Probing container should mark readiness on pods to false while pod is in progress of terminating when a pod has a readiness probe Not sure. At least as of July 27, 2022, but probably earlier than that. No response ! /sig node
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 node
/assign we should use listwatch to monitor pod status changes accurately, this interval 2s may lose pod change and cause the test failure
we did the same recently in another test, didn't we? I can't find the PR
sorry, i have not committed yet. do you plan to fix this test again? if so, I can unassign
he, no sorry for the confusion, I thought you were the one that fixed it, maybe it was ? There was one e2e that was flake and was solved using a listwatch instead of polling it every few seconds, I was trying to find the PR to show you , in case it can give you some idea ... please go ahead and fix it :)
this one?
yeah, so my memory was good then, I've identified the right author :smile:
I didn't understand what you said at first, but now I understand :smile:
Change:
function create-kube-controller-manager-opts(){ cat <<EOF > ~/kube/default/kube-controller-manager KUBE_CONTROLLER_MANAGER_OPTS="--master=127.0.0.1:8080  <del> --machines=$1  </del> --logtostderr=true" EOF

Discussion:
This flag is deprecated and no longer has any effect.
I wonder which version does this include.Now ubuntu approach is using ubuntu 0.15.0.
This change was checked in this week, so it will be true for clusters at 0.18.0+ (once the next release is cut next week). So the next time the ubuntu documentation is updated, this change should be reflected.
Ohit means that minion node can be automatically discovered by the master node when then kubelet set ? No other configuration is needed?
Yes, the kubelet, when passed the location of the apiserver, will register itself and then post node update messages. The only part that may depend on your deployment environment is the set of addresses that the kubelet passes to the apiserver. They will be based on the name of the node, reverse resolving the name of the node, or checking for addresses from the cloud provider.
Got it.I will include this when I updates the doc and scripts. Besides, I have a little questions here. Eric told me the addon services do not have service-account now.Will 0.18.0+ have it?
Service accounts will be included as part of 0.18.0 as well.
got it
- makes sense
Change:
"reflect" "sync" "testing" <del> "time" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet/leaky" "github.com/GoogleCloudPlatform/kubernetes/pkg/registry/registrytest" <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" </del> ) type podInfoCall struct {

Discussion:
Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.