jiebi/CodeConvo huggingface dataset:
Change:
Command:         []string{"testCommand"}, WorkingDir:      "testWorkingDir", SecurityContext: &v1.SecurityContext{ <del> RunAsNonRoot: &RunAsNonRoot, </del> <ins> RunAsNonRoot: &runAsNonRootTrue, </ins> RunAsUser:    &runAsUser, }, },

Discussion:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubelet securitycontext Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): 1.7.0-beta/1.8.0 (HEAD) Environment: Cloud provider or hardware configuration: gce OS (e.g. from /etc/os-release): gci Kernel (e.g. ): Install tools: Others: docker runtime (rkt seems to have a different code path, but I haven't checked it) What happened: containers could not run as root when "RunAsNonRoot=false" What you expected to happen: containers could run as root How to reproduce it (as minimally and precisely as possible): add a securitycontext to a container, don't set privileged, do set RunAsNonRoot, use an image that runs as root. The PodSecurityPolicy admission controller will always set a securitycontext if it's not specified, and cause this to be hit more often. Anything else we need to know: The bug is in the checks here: I have a fix in but that going in depends on an extension being granted. We may want to fix the bug regardless.
/sig node
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
I'll send a fix shortly.
Change:
} dv.SetBytes(data) } else { <del> dv.Set(reflect.Zero(dt)) </del> <ins> dv.Set(reflect.MakeSlice(dt, 0, 0)) </ins> } return nil }

Discussion:
I have created the following secret in my cluster. When I add labels to my secret and try to apply it in the cluster I get the following error This also happens when I use or using the go client. Not sure why, but works. I expect that the secret can be updated with the new labels since the is not actually changed. Steps explained above. No response <details</details<detailsKind </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 cli
/assign
/remove-sig cli /sig apps
Change:
} m := master.New(config) <del> // We serve on 3 ports.  See docs/reaching_the_api.md </del> <ins> // We serve on 3 ports.  See docs/accessing_the_api.md </ins> roLocation := "" if s.ReadOnlyPort != 0 { <del> roLocation = net.JoinHostPort(config.PublicAddress.String(), strconv.Itoa(config.ReadOnlyPort)) </del> <ins> roLocation = net.JoinHostPort(config.PublicAddress.String(), strconv.Itoa(s.ReadOnlyPort)) </ins> } secureLocation := "" if s.SecurePort != 0 { secureLocation = net.JoinHostPort(config.PublicAddress.String(), strconv.Itoa(s.SecurePort)) } <del> rwLocation := net.JoinHostPort(s.Address.String(), strconv.Itoa(int(s.Port))) </del> <ins> wideOpenLocation := net.JoinHostPort(s.Address.String(), strconv.Itoa(s.WideOpenPort)) </ins> // See the flag commentary to understand our assumptions when opening the read-only and read-write ports.

Discussion:
Trying to hit the read-write kubernetes service from inside a cluster does not work. tailing the kube-proxy logs shows: And sure enough, kube-apiserver is not listening on the NIC on that port. 8080 is only for the localhost HTTP communications between master components (and nginx redirect after HTTPS termination). The "kubernetes" master service needs to get created with Port set to 443.
+1
This needs to be port 6443 the auth_port On Feb 6, 2015 10:14 AM, "Paulo Pires" wrote:
The code says 8443, but then a flag changes to 6443. Will fix. , Eric Tune wrote:
Holy macaroni this is a mess. , Tim Hockin wrote:
Change:
return fmt.Errorf("failed to try resolving symlinks in path %q: %v", path, err) } path = evaluated <del> f, err := os.Open(path) </del> <ins> f, err := openFileShareDelete(path) </ins> if err != nil { return fmt.Errorf("failed to open log file %q: %v", path, err) }

Discussion:
The test is failing on Windows [0]: The idea of the test is to check that kubelet still follows and reads the Container Logs after a Log Rotation occured. However, because the followed file is open, it cannot be renamed, and thus, the container logs cannot be rotated. This issue could be prevented if the file would be opened with the [0] [1] Kubelet should not block container log rotation. Run the test ` is failing on Windows. /sig windows /kind bug /kind failing-test latest, master. This unit test has been failing for a while. N/A Windows nodes </detailsN/A N/A N/A
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind failing-test /sig windows
Change:
}, }, { <del> name: "custom extra-args", </del> <ins> name: "custom extra-args for v1.12.0-beta.2", </ins> cfg: &kubeadmapi.ClusterConfiguration{ Networking:                 kubeadmapi.Networking{PodSubnet: "10.0.1.15/16"}, ControllerManagerExtraArgs: map[string]string{"node-cidr-mask-size": "20"}, CertificatesDir:            testCertsDir, <del> KubernetesVersion:          "v1.7.0", </del> <ins> KubernetesVersion:          "v1.12.0-beta.2", </ins> }, expected: []string{ "kube-controller-manager",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When I use kubeadm to create an old version k8s cluster, the controller manager pod can not work well. The command like this : "kubeadm init --kubernetes-version=v1.11.2" The error of kube controller manager pod like this : What you expected to happen: The controller manager pod can work well. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.0 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): Install tools: kubeadm Others:
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
/remove-sig contributor-experience /area kubeadm
Please, use when filing kubeadm issues. /sig cluster-lifecycle
OK, thank you for reminding me.
Change:
fi } <del> find-release-tars() { SERVER_BINARY_TAR="${KUBE_ROOT}/server/kubernetes-server-linux-amd64.tar.gz" RELEASE_DIR="${KUBE_ROOT}/server/" if [[ ! -f "$SERVER_BINARY_TAR" ]]; then SERVER_BINARY_TAR="${KUBE_ROOT}/_output/release-tars/kubernetes-server-linux-amd64.tar.gz" RELEASE_DIR="${KUBE_ROOT}/_output/release-tars/" fi if [[ ! -f "$SERVER_BINARY_TAR" ]]; then echo "!!! Cannot find kubernetes-server-linux-amd64.tar.gz" exit 1 fi } </del> rackspace-set-vars() { CLOUDFILES_CONTAINER="kubernetes-releases-${OS_USERNAME}"

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:
}}, }, { <ins> name: "pods list logs: default container should not leak across pods", obj: &corev1.PodList{ Items: []corev1.Pod{ { TypeMeta: metav1.TypeMeta{ Kind:       "pod", APIVersion: "v1", }, ObjectMeta: metav1.ObjectMeta{ Name:      "foo", Namespace: "test", Labels:    map[string]string{"test": "logs"}, Annotations: map[string]string{ "kubectl.kubernetes.io/default-container": "c1", }, }, Spec: corev1.PodSpec{ RestartPolicy: corev1.RestartPolicyAlways, DNSPolicy:     corev1.DNSClusterFirst, Containers: []corev1.Container{ {Name: "c1"}, {Name: "c2"}, }, }, }, { TypeMeta: metav1.TypeMeta{ Kind:       "pod", APIVersion: "v1", }, ObjectMeta: metav1.ObjectMeta{ Name:      "bar", Namespace: "test", Labels:    map[string]string{"test": "logs"}, }, Spec: corev1.PodSpec{ RestartPolicy: corev1.RestartPolicyAlways, DNSPolicy:     corev1.DNSClusterFirst, Containers: []corev1.Container{ {Name: "c2"}, }, }, }, }, }, actions: []testclient.Action{ getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), getLogsAction("test", &corev1.PodLogOptions{Container: "c2"}), }, expectedSources: []corev1.ObjectReference{{ Kind:       "pod", APIVersion: "v1", Name:       "foo", Namespace:  "test", FieldPath:  fmt.Sprintf("spec.containers{%s}", "c1"), }, { Kind:       "pod", APIVersion: "v1", Name:       "bar", Namespace:  "test", FieldPath:  fmt.Sprintf("spec.containers{%s}", "c2"), }}, }, { </ins> name: "pods list logs: all containers", obj: &corev1.PodList{ Items: []corev1.Pod{*testPodWithTwoContainersAndTwoInitContainers()},

Discussion:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /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:
esac done <del> if [ "${golangci_config}" ]; then golangci+=(--config="${golangci_config}") fi </del> # Below the output of golangci-lint is going to be piped into sed to add # a prefix to each output line. This helps make the output more visible # in the Prow log viewer ("error" is a key word there) and ensures that

Discussion:
This is a subset of "make verify doesn't work under anymore" xref: In two places we assume the path for "local builds" But when dockerized it will be at should work.
I'm not sure what the cleanest solution is here. Maybe a symlink in a fixed location that we update to point to whichever we just built ...
cc
Can we set env variables as part of ? golangci-lint doesn't support a search path for plugins yet, but perhaps that can be .
Bit of a blunt instrument but we could do that. Another blunt approach would be picking some unused path under _output to add a symlink to either I guess.
It would be really nice if we could just pass searchpaths for the plugins instead of having to pass a complete path.
relative paths are resolved relative to the config file, so you can indirectly change a root path on a fixed file by using different config paths and not have to edit the file contents ... we could use two symlinks in _output to the actual config file. Still not ideal.
This is one of the few remaining verify scripts that doesnt work on mac or otherwise dockerized.
Let's fix this by making the path absolute in a temporary copy of the golangci-lint config file: Syncing .git is relevant for testing PRs, but it seems that already ensured that it is available.
That sounds reasonable. Yeah, while working on that issue I found the other handful of verify scripts that are also broken when containerized for reasons unrelated to git. This is one of them, the others are linked in
Change:
package handlers import ( <del> "encoding/json" </del> "fmt" "k8s.io/apimachinery/pkg/conversion/unstructured" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/types" <ins> "k8s.io/apimachinery/pkg/util/json" </ins> "k8s.io/apimachinery/pkg/util/strategicpatch" "github.com/evanphx/json-patch"

Discussion:
When patching, in the type decoded from ToUnstructured mismatch with the one decoded form json.Unmarshal for numbers. Example: port: 80 in original object has type int64 port: 80 in original object has type float64 This is the root cause of
Change:
testDeploymentDefaultReplicas := int32(2) testDeploymentMinimumReplicas := int32(1) testDeploymentNoReplicas := int32(0) <ins> testDeploymentAvailableReplicas := int32(0) </ins> testDeploymentLabels := map[string]string{"test-deployment-static": "true"} testDeploymentLabelsFlat := "test-deployment-static=true" w := &cache.ListWatch{

Discussion:
I started missing error checks. When adding error checking to this call here, the test started to fail: The test should have continued to work when checking the error. No response <detailsmaster </details<details</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 apps
/priority important-soon can you or someone in apps PTAL?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
/assign
/assign
Change:
return strings.Contains(err.Error(), "Retriable: true") } <ins> // HasStatusForbiddenOrIgnoredError return true if the given error code is part of the error message // This should only be used when trying to delete resources func HasStatusForbiddenOrIgnoredError(err error) bool { if err == nil { return false } if strings.Contains(err.Error(), fmt.Sprintf("HTTPStatusCode: %d", http.StatusNotFound)) { return true } if strings.Contains(err.Error(), fmt.Sprintf("HTTPStatusCode: %d", http.StatusForbidden)) { return true } return false } </ins>

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 --What happened: controller-manager is stuck in deleting an incorrectly configured LB type service. it cannot be recovered until restarted. What you expected to happen: controller-manager should recover. At least it should allow us to create the service without restarting it. How to reproduce it (as minimally and precisely as possible): put a random IP in above yaml and make sure the resource group doen't exist. Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig azure
I also want to add that the above repro is stuck in 403. It's possible for it to be stuck in 404 as well when the SP has the right permission.
Can you share the log for 404?
Thanks for reporting the issue. /assign Do you mean other services couldn't be configured when this happens?
correct.
FYI, we had the same issue when the Idle Timeout annotation was set to "3" which isn't a supported case. Will this PR also cover this edge case ?
Unfortunately , this is still not fixed. The idle timeout is not 403 or 404. We need another fix for this (and possibly more for other annotations)
Change:
continue } pv, err = config.client.CoreV1().PersistentVolumes().Get(backgroundCtx, pv.Name, metav1.GetOptions{}) <del> if apierrors.IsNotFound(err) { </del> <ins> if apierrors.IsNotFound(err) || errors.Is(err, context.Canceled) { </ins> continue } // Delete and create a new PV for same local volume storage

Discussion:
master-informing: gce-cos-master-serial ! 2023-06-08 20:01:55 +0000 UTC { failed [FAILED] PV Create API error: Post "https://35.247.13.135/api/v1/persistentvolumes": context canceled In [DeferCleanup (Each)] at: test/e2e/storage/persistentvolumes- @ 06/09/23 18:05:53.165 } No response_ /sig storage cc
I think we did something wrong in /triage accepted
/assign
do you have a link to a full log? It's not clear where comes from (will look closer on Monday), but as the test is shutting down, not allowing new PVs to be created may be normal.
Never mind, the description has links to failing jobs.
ok - this looks like an actual bug with the code as written. what's happening is the "Stop and wait.." at line 492 is calling of the passed to the "goroutine [that] recycle[s] unbound PVs". Ordinarily that signal triggers the and the goroutine exits. In this case (and it will be flaky) it triggers while the case is running and it causes the on line 533 to error with . I don't know what the desired behavior is - should a error be ignored since we're signaling that it's time to leave? or should we actually wait for the to complete and use a different (timeout??) context for that instead.
one potential (if complex) fix is to pass two contexts down to the goroutine. one, to signal “you should stop when you are next at the select statement” and another , that is passed down to CreatePV that signals “stop immediately”. The would then take a Ginkgo context with a timeout. when the first launches it cancels and then if the timeout expires it cancels there might well be a simpler way to track all this but the very nature of what this goroutine is doing seems to need some sort of two-signal approach. alternatively: we can say that within this goroutine is always safe to ignore. it’s simpler as long as there are no test pollution concerns about forcibly canceling the CreatePV.
Patrick is the most knowledgable person in this area, we should wait for his response
Sounds good.

This might be a one off - or they may be a class of flaky tests that have a similar structure and so coming up with, and applying, a common pattern for signaling a background goroutine to exit gracefully could be useful.
I think ignoring the error is fine in this case. There is no reason for it to occur except when the test has already completed. -
sounds good - I suppose the only concern would be that forcibly aborting the might be an issue (e.g. the server's still working on things and we fail to clean up or race with it). but y'al lknow k8s far better than i do so maybe there's reasons to have confidence that it's a nonissue.
If the operation completes on the server side, then the other registered earlier will delete the PV.
last run was green let's see this is stable now, thanks for the help
Change:
hack/dev-build-and-up.sh ``` <ins> The script above relies on Google Storage to deploy the software to instances running in GCE. It uses the Google Storage APIs so the "Google Cloud Storage JSON API" setting must be enabled for the project in the Google Developers Console (https://cloud.google.com/console#/project). The instances must also be able to connect to each other using their private IP. The script uses the "default" network which should have a firewall rule called "default-allow-internal" which allows traffic on any port on the private IPs. If this rule is missing from the default network or if you change the network being used in `cluster/config-default.sh` create a new rule with the following field values: * Source Ranges: 10.0.0.0/8 * Allowed Protocols or Port: tcp:1-65535;udp:1-65535;icmp </ins> ### Running a container (simple version) Once you have your instances up and running, the `build-go.sh` script sets up

Discussion:
Before enabling the cloud storage API, I'm unable to launch the test cluster. dev-build-and- appears to run successfully, but hangs at the end as the machines have not been properly configured. From on the kubernetes-master: AccessDeniedException: 403 Access Not Configured. Please go to the Google Developers Console () for your pro ject, select APIs and Auth and enable the Google Cloud Storage JSON API.