jiebi/CodeConvo huggingface dataset:
Change:
} function upgrade-master() { <ins> local num_masters num_masters=$(get-master-replicas-count) if [[ "${num_masters}" -gt 1 ]]; then echo "Upgrade of master not supported if more than one master replica present. The current number of master replicas: ${num_masters}" exit 1 fi </ins> echo "== Upgrading master to '${SERVER_BINARY_TAR_URL}'. Do not interrupt, deleting master instance. ==" # Tries to figure out KUBE_USER/KUBE_PASSWORD by first looking under

Discussion:
Script does not support upgrade of clusters with HA master setup.
CC
PR does not allow to run upgrade scripts on cluster with HA masters. The upgrade scenario for HA clusters from 1.5 to 1.6 may be the following: all master replicas but one, master upgrade, master replicas again.
I haven't reviewed the PR yet, but the scenario you are proposing defeats the purpose of HA master! I think it's ok to say we do not support HA master upgrades yet, but we should document how this can be done manually and fix this properly later by adding support in
It's too late to add this in for 1.6.0, but we should consider backporting a fix so that users can update an HA master to 1.6.x in the near future. We should also put in a big warning in the release notes warning users not to try and upgrade if they deployed an HA master using kube-
/sig cluster-lifecycle
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. Prevent issues from auto-closing with an comment. 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 /lifecycle frozen
/remove-lifecycle frozen /sig cloud-provider /area provider/gcp changing with ownership of ""
/remove-sig cluster-lifecycle
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or .

/close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
Change:
// GetSELinuxSupport tests if pathname is on a mount that supports SELinux. // Not implemented for testing func (hu *FakeHostUtil) GetSELinuxSupport(pathname string) (bool, error) { <del> return false, errors.New("GetSELinuxSupport not implemented") </del> <ins> return false, nil </ins> } // GetMode returns permissions of pathname.

Discussion:
On a busy system, kubelet failed to tell the container runtime that a pod's CSI volume supports SELinux and should be relabeled with pod's SELinux label. The pod then can't access the volume. Kubelet correctly detects that the CSI volume supports SELinux and tells the container runtime to relabel it. Unknown. Get a busy system and try hard? CSI volume plugin tried to detect that the volume supports SELinux during SetupAt. This check failed: Current CSI volume plugin code silently consumes the error and assumes that the volume does not support SELinux at all: Therefore, the volume is marked as mounted and given to the container runtime without the right SELinux options and the runtime does not relabel volume. <details22.0 </details<detailsNone </details<details</details<details</details<detailsCRI-O, but I think it's not really relevant. </details<details</details
/sig storage /triage accepted
We've updated kubelet in our clusters to v1.20.13 (which contains the cherry picked fix), but still observe the issue
Change:
CROSS_BUILD_COPY qemu-QEMUARCH-static /usr/bin/ # Base Packages <del> RUN yum install -y wget strace psmisc procps-ng ceph ceph-fuse && yum clean all </del> <ins> RUN yum install -y wget strace psmisc procps-ng ceph ceph-fuse hostname && yum clean all </ins> # Get ports exposed EXPOSE 6789

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! If the matter is security related, please disclose it privately via --When I run some e2e storage testcases locally, below testcases as an example, I consistently saw the below error message, ceph should be deployed successfully and testcase should pass. Run the testcases mentioned above. e.g. Kubernetes version (use ): ALL Cloud provider or hardware configuration: ARM64 OS (e.g: ): ubuntu18 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig testing /sig storage
/assign
is this happening in CI? please provide links to occurences?
Hey, Ben, I update the issue description a little bit, this won't be an issue on X86 which is currently the default arch CI is running, but tons of testcases will fail on ARM64 due to this issue. Eventually, we hope the k8s will have a ARM CI along with the more adoption of arch beside the X86, and thus, those e2e testcases should workable on ARM64 firstly. I will explain why it failed on ARM64 in the PR desc, pls help to review, thanks!
/triage accepted
Change:
APIVersion: "v1", FieldPath:  "spec.containers[2]", }, <del> Reason:  "Started", Message: "some verbose message: 1", Source:  v1.EventSource{Component: "eventTest"}, Count:   2, Type:    v1.EventTypeNormal, </del> <ins> Reason:              "Started", Message:             "some verbose message: 1", Source:              v1.EventSource{Component: "eventTest"}, ReportingController: "eventTest", Count:               2, Type:                v1.EventTypeNormal, </ins> }, expectLog:    `Event(v1.ObjectReference{Kind:"Pod", Namespace:"baz", Name:"foo", UID:"bar", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers[2]"}): type: 'Normal' reason: 'Started' some verbose message: 1`, expectUpdate: true,

Discussion:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted
Change:
bufferSize int decoder decoder <del> rawData []byte </del> } type JSONSyntaxError struct { <del> Line int Err  error </del> <ins> Offset int64 Err    error </ins> } func (e JSONSyntaxError) Error() string { <del> return fmt.Sprintf("json: line %d: %s", e.Line, e.Err.Error()) </del> <ins> return fmt.Sprintf("json: offset %d: %s", e.Offset, e.Err.Error()) </ins> } type YAMLSyntaxError struct {

Discussion:
This bug was privately disclosed and told to open here. What happened: NewYAMLOrJSONDecoder from has an index out of bounds issue which can cause callers to panic. Download attached reproducer file Run golang test: When run with v0.19.3: Additionally, this can be seen in kubectl directly (below is kubectl 1.20.0): Environment: Kubernetes version (use ): Verified with 1.19, 1.20
/sig api-machinery
This piece attempts to find line+column position of a json syntax error. To do that it assumes that full input is available which is not true: is : is only the first data chunk: The subject happens e.g. when syntax error offset is past buffer size and Test to reproduce the panic: I am not sure it is easily possible to find line+column of json syntax error as full input may not be available. Maybe it should only attempt to find line+column if offset is within the first chunk (i.e. below buffer size).
Line number calculation in and updated in
do you want to submit a patch to with a defensive check to avoid the panic ( compare and )
I have raised a discussion on having line number in the . The consensus there is that it should be possible to count lines with a full input at hand and it does not worth to have it in the core library due to performance impact and maintenance costs. The problem of here is that it attempts to find out line number without having full input at hand. I think the defensive patch is not the right approach because line calculation is incorrect anyway even when there is no panic: begins at a value with a syntax error, i.e. in a stream of two values and syntax error in the second value it would contain only the second value and thus new lines in the first value in the stream would not be counted. I think the following options are there: to stream taken from . This is straightforward but changes interface. I can not find any code that uses field, it is only used in the error message that would change: line number only if offset is within the length of the first data chunk (). I am not sure what would be the unknown line number then, perhaps. line number properly during stream decoding, see This has some performance penalty as line number is calculated in any case even if there is no syntax error, i.e.

in the majority of the cases.
cc /triage accepted
This is probably acceptable.
I have opened a PR
Thank you for support.
Change:
pushd "staging/src/k8s.io/${repo}" >/dev/null 2>&1 echo "=== propagating to ${repo}" >> "${LOG_FILE}" # copy root go.mod, changing module name <del> sed "s#module k8s.io/kubernetes#module k8s.io/${repo}#" < "${KUBE_ROOT}/go.mod" > "${KUBE_ROOT}/staging/src/k8s.io/${repo}/go.mod" </del> <ins> sed "s#module k8s.io/kubernetes#module k8s.io/${repo}#"  < "${KUBE_ROOT}/go.mod"  > "${KUBE_ROOT}/staging/src/k8s.io/${repo}/go.mod" </ins> # remove `require` directives for staging components (will get re-added as needed by `go list`) <del> kube::util::list_staging_repos | xargs -n 1 -I {} echo "-droprequire k8s.io/{}"   | xargs -L 100 go mod edit </del> <ins> kube::util::list_staging_repos  | while read -r X; do echo "-droprequire k8s.io/${X}"; done  | xargs -L 100 go mod edit </ins> # rewrite `replace` directives for staging components to point to peer directories <del> kube::util::list_staging_repos | xargs -n 1 -I {} echo "-replace k8s.io/{}=../{}" | xargs -L 100 go mod edit </del> <ins> kube::util::list_staging_repos  | while read -r X; do echo "-replace k8s.io/${X}=../${X}"; done  | xargs -L 100 go mod edit </ins> popd >/dev/null 2>&1 done

Discussion:
I ran update- Not to see a ton of errors Kubernetes version (use ): HEAD of master
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig architecture (code organization / dependencies) /sig testing (hack scripts)
/triage accepted
Change:
CLOUD_CONFIG=${CLOUD_CONFIG:-""} KUBELET_PROVIDER_ID=${KUBELET_PROVIDER_ID:-"$(hostname)"} FEATURE_GATES=${FEATURE_GATES:-"AllAlpha=false"} <ins> EMULATED_VERSION=${EMULATED_VERSION:+kube=$EMULATED_VERSION} </ins> CPUMANAGER_POLICY=${CPUMANAGER_POLICY:-""} CPUMANAGER_RECONCILE_PERIOD=${CPUMANAGER_RECONCILE_PERIOD:-""} CPUMANAGER_POLICY_OPTIONS=${CPUMANAGER_POLICY_OPTIONS:-""}

Discussion:
Currently the local-up- script does not have support for the flag. This flag was recently here as a part of For development, testing, and full plumbing through of the feature the flag should be to local-up- to allow for usage of the feature when setting up a cluster via local-up-
/sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig apimachinery 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
/sig api-machinery
/sig testing /triage accepted /assign
Change:
errs = append(errs, validateScorePluginSetForConflictPlugins( pluginsPath.Child("score"), apiVersion, profile)...) } <ins> seenPluginConfig := make(sets.String) for i := range profile.PluginConfig { pluginConfigPath := path.Child("pluginConfig").Index(i) name := profile.PluginConfig[i].Name args := profile.PluginConfig[i].Args if seenPluginConfig.Has(name) { errs = append(errs, field.Duplicate(pluginConfigPath, name)) } else { seenPluginConfig.Insert(name) } if removed, removedVersion := isPluginRemoved(apiVersion, name); removed { errs = append(errs, field.Invalid(pluginConfigPath, name, fmt.Sprintf("was removed in version %q (KubeSchedulerConfiguration is version %q)", removedVersion, apiVersion))) } else if validateFunc, ok := m[name]; ok { // type mismatch, no need to validate the `args`. if reflect.TypeOf(args) != reflect.ValueOf(validateFunc).Type().In(1) { errs = append(errs, field.Invalid(pluginConfigPath.Child("args"), args, "has to match plugin args")) } else { in := []reflect.Value{reflect.ValueOf(pluginConfigPath.Child("args")), reflect.ValueOf(args)} res := reflect.ValueOf(validateFunc).Call(in) // It's possible that validation function return a Aggregate, just append here and it will be flattened at the end of CC validation. if res[0].Interface() != nil { errs = append(errs, res[0].Interface().(error)) } } } } </ins> return errs }

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! If the matter is security related, please disclose it privately via --Have a legacy scheduler config, upgrade to v1beta2 since we are at v1beta2 now, scheduler failed to start with some unreadable raw data, accurate and readable error message. config scheduler config like what has been said above. Kubernetes version (use ): latest. Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig scheduling /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
Change:
assert.NoError(t, err) fakePodGetter := m.containerGC.podGetter.(*fakePodGetter) <del> makeGCSandbox := func(pod *v1.Pod, attempt uint32, state runtimeapi.PodSandboxState, withPodGetter bool) sandboxTemplate { </del> <ins> makeGCSandbox := func(pod *v1.Pod, attempt uint32, state runtimeapi.PodSandboxState, withPodGetter bool, createdAt int64) sandboxTemplate { </ins> if withPodGetter { // initialize the pod getter fakePodGetter.pods[pod.UID] = pod } return sandboxTemplate{ <del> pod:     pod, state:   state, attempt: attempt, </del> <ins> pod:       pod, state:     state, attempt:   attempt, createdAt: createdAt, </ins> } }

Discussion:
kubernetes pre-submit unit tests for pass some times and fails some times causing the flakiness. Here is one such failure https://k8s- Passing: Failing: cc
Yep, I'm checking with this
Sorry for introducing a flakiness. Sent out the fix in .
/assign
Dup of . /close

https://k8s- Failed: TestSandboxGC {kuberuntime}
https://k8s- Failed: TestSandboxGC {kuberuntime}
/assign
Should've been fixed by
Change:
return new(int64), "", nil } <del> // isInitContainerFailed returns true if container has exited and exitcode is not zero // or is in unknown state. </del> <ins> // isInitContainerFailed returns true under the following conditions: // 1. container has exited and exitcode is not zero. // 2. container is in unknown state. // 3. container gets OOMKilled. </ins> func isInitContainerFailed(status *kubecontainer.Status) bool { <ins> // When oomkilled occurs, init container should be considered as a failure. if status.Reason == "OOMKilled" { return true } </ins> if status.State == kubecontainer.ContainerStateExited && status.ExitCode != 0 { return true }

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:
pod.UID = types.UID(hex.EncodeToString(hasher.Sum(nil)[0:])) glog.V(5).Infof("Generated UID %q for pod %q from URL %s", pod.UID, pod.Name, url) } <ins> // This is required for backward compatibility, and should be removed once we // completely deprecate ContainerManifest. if len(pod.Name) == 0 { pod.Name = string(pod.UID) glog.V(5).Infof("Generate Name %q from UID %q from URL %s", pod.Name, pod.UID, url) } </ins> if len(pod.Namespace) == 0 { hasher := adler32.New() fmt.Fprint(hasher, url)

Discussion:
I'm trying containervm with kubelet built from head and this YAML file: The YAML file is v1beta2 and doesn't set a name to the Pod. When starting kubelet, it doesn't start the "nc" echo server and complains about this on the logs: Chatting with on IM she mentioned it might be due to a change from that now requires non-empty pod names (replaces random generation with validation for non-emptiness) but that means all existing YAML files (even the ones with an older version) will stop working... Is that expected? Thanks! Filipe
Yes, the latest kubelet call validation on all sources: etcd, file, http, etc. now, and PodName is a required field. One potential fix for this is also invoke conversion code before call validation, like what we have done at apiserver. Thoughts?
Just so I get unblocked... Do you have an example YAML file that will set the pod name and will work? Right now this is what I'm using: Should I bump up version to v1beta3 and include a new field somewhere? Thanks! Filipe
The type of that yaml is not pod, and the kubelet code doesn't know how to read pods from a file. So, I think change needs to be reverted before you can make the next ContainerVM release. The v1beta2 vs v1beta3 should not have anything to do with it, unless I'm misunderstanding.
Or will it work to do this:
Still, not sure if you want to release a containerVM version that doesn't accept the old format?
Thanks I made it work with the YAML above! I still have errors in the logs: But the docker containers are being brought up... It's weird that is the YAML field that is missing, considering the source seems to say it's a deprecated field that will be removed at some point... I agree with your point that this needs to be fixed at head before the next containervm release. I opened to increase test coverage of standalone kubelet since we have been seeing many changes break that model recently. Cheers, Filipe
id in v1beta2 maps to name in v1beta3 Tim's change made name required. The internal representation is like v1beta3.

But v1beta3 is not officially stable so we don't want to use it in the GKE or containerVM docs.
The issue is caused by , and affect both v0.8 and v0.9 release for standalone kubelet to support old format ContainerManifests.
Ugh, I thought ID was really required. I spoke with Dawn a bit, and here's my thinking. 1) update all our docs and examples to include ID 2) in file and HTTP config sources, check for Name = "" and apply a default, maybe log a warning that this is deprecated 3) wait for the ContainerManifest -Pod conversion to really make it required
Change:
return err } <del> o.Namespace, _, err = f.ToRawKubeConfigLoader().Namespace() </del> <ins> o.Namespace, o.EnforceNamespace, err = f.ToRawKubeConfigLoader().Namespace() </ins> if err != nil { return err }

Discussion:
I'm writing a small bash script which generates some k8s resources in a namespace (other than ). When using to generate a service, the yaml which is generated does not include the defined namespace. I've also tried to move around the argument to the beginning (i.e. , but that doesn't work as well. Generated yaml should include the , when it's defined as an option. Kubernetes version (use ): Cloud provider or hardware configuration: n/a (not really important) OS (e.g: ): Kernel (e.g. ): Install tools: kubectl Network plugin and version (if this is a network-related bug): n/a Others: /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
/sig cli
/assign