Question: count := 0 for { <-timer.C <del> n, err := w.Write([]byte("w")) </del> <ins> n, err := w.Write(responseBody[count : count+1]) </ins> if err != nil { return } flusher.Flush() count += n <del> if count == watchExpectSendBytes { </del> <ins> if count == len(responseBody) { </ins> return } } }) <del> mux := http.NewServeMux() mux.Handle(urlNormal, WithProbabilisticGoaway(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { </del> <ins> getHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { </ins> w.WriteHeader(http.StatusOK) <del> w.Write([]byte("hello")) </del> <ins> w.Write(responseBody) </ins> return <del> }), 0)) mux.Handle(urlWatch, WithProbabilisticGoaway(watchHandler, 0)) mux.Handle(urlGoaway, WithProbabilisticGoaway(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { </del> <ins> }) postHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { reqBody, err := ioutil.ReadAll(r.Body) if err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } if !reflect.DeepEqual(requestPostBody, reqBody) { http.Error(w, fmt.Sprintf("expect request body: %s, got: %s", requestPostBody, reqBody), http.StatusBadRequest) return } </ins> w.WriteHeader(http.StatusOK) <del> w.Write([]byte("hello")) </del> <ins> w.Write(responseBody) </ins> return <del> }), 1)) </del> <ins> }) mux := http.NewServeMux() mux.Handle(urlGet, WithProbabilisticGoaway(getHandler, 0)) mux.Handle(urlPost, WithProbabilisticGoaway(postHandler, 0)) mux.Handle(urlWatch, WithProbabilisticGoaway(watchHandler, 0)) mux.Handle(urlGetWithGoaway, WithProbabilisticGoaway(getHandler, 1)) mux.Handle(urlPostWithGoaway, WithProbabilisticGoaway(postHandler, 1)) </ins> mux.Handle(urlWatchWithGoaway, WithProbabilisticGoaway(watchHandler, 1)) s := httptest.NewUnstartedServer(mux)

What happened: We enabled feature in our large-scale cluster, and we found client(Kubelet) may got error(500 http code response) like after received GOAWAY frame. I had already re-produce this bug and open an in golang repo. So far I think this bug only occur with a small probability when client request server in high concurrency use a same httpclient instance, and it's a golang sdk bug in http client. Before I solved this issue, I suggest do NOT enable GOAWAY() feature. As it's a golang sdk bug(currently I known and doubt) in http client, revert GOAWAY feature(codes) is not necessary.
cc
/sig api-machinery
Thanks for the report.
Based on not setting the field, I think it defaults that way, so that's good. We will leave the option and filter so that when golang updates its client, we will have a simple way to turn it on and execute it.
Sure. I am trying to fix the golang http client issue and will update progress at . After golang http client issue fixed, I will add more concurrent test cases to see if there are any other bugs may occur by GOAWAY feature. BTW, we still enable GOAWAY feature in our production cluster, because there is no any evidence told us this error will influence SLO, as all most components(kubelet, controller-manager, scheduler) is controller work mode and will re-try after got error. /assign
Golang version or required, which will release at 07/01/2020.
Kubernetes v1.19(or master branch) now is using golang 1.15, and golang 1.15 has fixed the issue. And is on going. Let me add more test cases to ensure the error will not happen again.
I think we should re-open this issue because of . /re-open


Question: if fail && err == nil { t.Errorf("expecting failure, but got no err") } <del> if attachID != id && !fail { t.Errorf("expecting attachID %v, got %v", id, attachID) </del> <ins> if attachID != "" { t.Errorf("expecting empty attachID, got %v", attachID) </ins> } <del> }(tc.spec, tc.attachID, tc.nodeName, tc.shouldFail) </del> <ins> }(tc.spec, tc.nodeName, tc.shouldFail) </ins> var status storage.VolumeAttachmentStatus if tc.injectAttacherError {

<!-- 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: Followup to In 1.15, we can merge this commit: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
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


Question: Labels:    map[string]string{"pod": name}, Resources: defaultPodRes, }) <del> // Setting grace period to zero. Otherwise, we may never see the actual deletion // of the pods in integration tests. </del> pod.Spec.TerminationGracePeriodSeconds = &grace return pod }

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Unknown yet. Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated /sig scheduling /help
Can I give it a try?
Sure, feel free to take it. /assign ahmad-diaa /remove-help
I keep trying to get it fail locally by running the following command: but it never does, am I doing something wrong? Is there something else that I should be doing and would be more helpful?
Sometimes the flake is hard to reproduce in local env. You may have to read the error log of the flakes thoroughly to get some clues. BTW: you can also run the test multiple times using the directive:
After looking through the logs I came up with some information that might be useful As far as I understand, the reason for the flake is the of the medium priority pod not being cleared That is because the update request for removing returns the following error: So my current guess is that might be outdated in some cases As I am not really familiar with the logic, I would like to know whether or not those are valid points so that I could dig deeper. What do you think?
If that's the case, you can set here: You can raise a PR and manually try for ~20 times to see you can reproduce the flake.
found another issue tracking this too. it seems it has been flaky for a while.
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution.
This sometimes happens. But we usually take the first PR unless it's clearly worked by someone. In terms of which style to resolve the Conflict error, I'm asking here:
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution. No worries, I haven't started implementing yet and your PR seems to be following the correct approach as well according to this:


Question: Labels:    map[string]string{"pod": name}, Resources: defaultPodRes, }) <del> // Setting grace period to zero. Otherwise, we may never see the actual deletion // of the pods in integration tests. </del> pod.Spec.TerminationGracePeriodSeconds = &grace return pod }

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: [TODO] Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig node These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry.


Question: Labels:    map[string]string{"pod": name}, Resources: defaultPodRes, }) <del> // Setting grace period to zero. Otherwise, we may never see the actual deletion // of the pods in integration tests. </del> pod.Spec.TerminationGracePeriodSeconds = &grace return pod }

Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: /sig scheduling
/assign
any progress on this one?
I was working on it and tried to find the root cause. I will give my solution within this week
Another one
Still happening cc
/assign
/close dupe
Closing this issue. <detailsIn response to : /close dupe 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


Question: Subsystem:         KubeletSubsystem, Name:              LastKnownGoodConfigKey, Help:              "The config source the node will fall back to when it encounters certain errors. The count is always 1.", <del> DeprecatedVersion: "1.23.0", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, []string{ConfigSourceLabelKey, ConfigUIDLabelKey, ConfigResourceVersionLabelKey, KubeletConfigKeyLabelKey},

This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
Reopened this issue. <detailsIn response to : /reopen 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
/cc
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
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon


Question: // // // <del> // // </del> // This must be line #50. var _ = ginkgo.Describe("framework", func() {

pull-kubernetes-unit Probably since it was merged in The test checks output from the E2E framework and sometimes some extra log output shows up that isn't expected: No response /sig testing
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


Question: zero := int64(0) <ins> // Create a pod to check the conntrack entries on the host node // It mounts the host /proc/net folder to be able to access // the nf_conntrack file with the host conntrack entries privileged := true hostExecPod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:      "e2e-net-exec", Namespace: fr.Namespace.Name, Labels:    map[string]string{"app": "e2e-net-exec"}, }, Spec: v1.PodSpec{ HostNetwork: true, NodeName:    clientNodeInfo.name, Containers: []v1.Container{ { Name:            "e2e-net-exec", Image:           kubeProxyE2eImage, ImagePullPolicy: "Always", Args:            []string{"pause"}, VolumeMounts: []v1.VolumeMount{ { Name:      "proc-net", MountPath: "/rootfs/proc/net", ReadOnly:  true, }, }, SecurityContext: &v1.SecurityContext{ Privileged: &privileged, }, }, }, Volumes: []v1.Volume{ { Name: "proc-net", VolumeSource: v1.VolumeSource{ HostPath: &v1.HostPathVolumeSource{ Path: "/proc/net", }, }, }, }, TerminationGracePeriodSeconds: &zero, }, } fr.PodClient().CreateSync(hostExecPod) defer fr.PodClient().DeleteSync(hostExecPod.Name, &metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) </ins> // Some distributions (Ubuntu 16.04 etc.) don't support the proc file. <del> _, err = e2essh.IssueSSHCommandWithResult( "ls /proc/net/nf_conntrack", framework.TestContext.Provider, clientNodeInfo.node) </del> <ins> _, err = framework.RunHostCmd(fr.Namespace.Name, "e2e-net-exec", "ls /rootfs/proc/net/nf_conntrack") </ins> if err != nil && strings.Contains(err.Error(), "No such file or directory") { framework.Skipf("The node %s does not support /proc/net/nf_conntrack", clientNodeInfo.name) } framework.ExpectNoError(err) <ins> // Create the client and server pods </ins> clientPodSpec := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:      "e2e-net-client",

Which jobs are failing: kops-aws and many other jobs Which test(s) are failing: This isn't the actual test, but the text we're consistently seeing is Since when has it been failing: Testgrid links: (ref: ) Reason for failure: TBD Anything else we need to know: Very rarely tests pass when one of the tests passes: Seems related to , that was merged about the same time:
/sig cluster-lifecycle /sig aws
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cluster-lifecycle /sig aws 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
/priority critical-urgent this is merge blocking
/assign /cc /cc /cc
The PR we think we want to revert
is also failing, I don't think this is aws-specific
/cc
/assign
it failed with kind too :/ with the same message
Opened to revert
/unassign /sig network /sig testing /remove-sig cluster-lifecycle
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
This may be the actual cause PR to address But we're going with revert first to be sure we've identified the offending PR
I think I've identified the root cause
Revert brought us back to green: Awaiting root cause fix
/remove-triage unresolved
/reopen merged but we're now seeing multiple tests fail since it merged Looking at it went red between these commits:
Reopened this issue. <detailsIn response to : /reopen merged but we're now seeing multiple tests fail since it merged 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 an attempt to fix
reverting in
is the failure cluster I suspect will go down once the revert goes in
/close Failure cluster has gone down, calling this done <img width="998" alt="Screen Shot 2020-01-10 at 9 56 17 AM" src="https://user-"
Closing this issue.


Question: zero := int64(0) <ins> // Create a pod to check the conntrack entries on the host node // It mounts the host /proc/net folder to be able to access // the nf_conntrack file with the host conntrack entries privileged := true hostExecPod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:      "e2e-net-exec", Namespace: fr.Namespace.Name, Labels:    map[string]string{"app": "e2e-net-exec"}, }, Spec: v1.PodSpec{ HostNetwork: true, NodeName:    clientNodeInfo.name, Containers: []v1.Container{ { Name:            "e2e-net-exec", Image:           kubeProxyE2eImage, ImagePullPolicy: "Always", Args:            []string{"pause"}, VolumeMounts: []v1.VolumeMount{ { Name:      "proc-net", MountPath: "/rootfs/proc/net", ReadOnly:  true, }, }, SecurityContext: &v1.SecurityContext{ Privileged: &privileged, }, }, }, Volumes: []v1.Volume{ { Name: "proc-net", VolumeSource: v1.VolumeSource{ HostPath: &v1.HostPathVolumeSource{ Path: "/proc/net", }, }, }, }, TerminationGracePeriodSeconds: &zero, }, } fr.PodClient().CreateSync(hostExecPod) defer fr.PodClient().DeleteSync(hostExecPod.Name, &metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) </ins> // Some distributions (Ubuntu 16.04 etc.) don't support the proc file. <del> _, err = e2essh.IssueSSHCommandWithResult( "ls /proc/net/nf_conntrack", framework.TestContext.Provider, clientNodeInfo.node) </del> <ins> _, err = framework.RunHostCmd(fr.Namespace.Name, "e2e-net-exec", "ls /rootfs/proc/net/nf_conntrack") </ins> if err != nil && strings.Contains(err.Error(), "No such file or directory") { framework.Skipf("The node %s does not support /proc/net/nf_conntrack", clientNodeInfo.name) } framework.ExpectNoError(err) <ins> // Create the client and server pods </ins> clientPodSpec := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:      "e2e-net-client",

<detailsIn response to : /close Failure cluster has gone down, calling this done <img width="998" alt="Screen Shot 2020-01-10 at 9 56 17 AM" src="https://user-"</details


Question: var shutdownChanMut sync.Mutex var connChan = make(chan struct{}, 1) <ins> lock.Lock() </ins> systemDbus = func() (dbusInhibiter, error) { defer func() { connChan <- struct{}{}

/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
/sig node
I find the reason for it, but I don't know the solution is suitable, correct me if not.
/triage accepted /assign


Question: return nil, toRelease, nil } <del> // if headless service then we bail out early (no clusterIPs management needed) if len(oldService.Spec.ClusterIPs) > 0 && oldService.Spec.ClusterIPs[0] == api.ClusterIPNone { return nil, nil, nil } </del> // upgrade and downgrade are specific to dualstack if !utilfeature.DefaultFeatureGate.Enabled(features.IPv6DualStack) { return nil, nil, nil

<!-- 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 --Patching a Kubernetes service failed with I the following yaml documents Create an external name service Change to to an ClusterIP Service Try to change it back to an external name service Kubernetes version (use ):Cloud provider or hardware configuration:
/sig node /sig api-machinery
Unsure if Service is part of networking /sig networking
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Unsure if Service is part of networking 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 network
/remove-sig node
/cc /triage accepted
It is part of networking :), actually this part of Services is being revisited these days /assign
ack.
/sig network
Please don't triage/accept issues unless you're SURE they are your sig's. This fell through cracks.
/assign
this does not repo on: Here is what i did: service (the same one above) the service and change to =OK the service and change to =OK I have also performed step 3 using and the result is also OK /triage needs-information
I was using client v1.21.0 - is it resolved in newer kubectl 1.21.x patches?
please do. And also please share the exact steps you used were you using kubectl edit? or replace? or patch?
It's in the description - kubectl apply
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accepted - working on a fix. 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
/triage accepted working on a fix
to confirm does the merged PR allow you to now change the type from to ? Or does it still produce an error with the difference it is reported properly vs. INTERNAL_ERROR? If it's the former can we cherry pick this PR back to supported K8s versions?


Question: return nil, toRelease, nil } <del> // if headless service then we bail out early (no clusterIPs management needed) if len(oldService.Spec.ClusterIPs) > 0 && oldService.Spec.ClusterIPs[0] == api.ClusterIPNone { return nil, nil, nil } </del> // upgrade and downgrade are specific to dualstack if !utilfeature.DefaultFeatureGate.Enabled(features.IPv6DualStack) { return nil, nil, nil

the former and we should be able to cherry pick it.
for another look.
Cherry picks made: 22 21 20


Question: target.Reset() func() { <ins> serviceResolver := tc.serviceResolver if serviceResolver == nil { serviceResolver = &mockedRouter{destinationHost: targetServer.Listener.Addr().String()} } </ins> handler := &proxyHandler{ localDelegate:   http.NewServeMux(), <del> serviceResolver: &mockedRouter{destinationHost: targetServer.Listener.Addr().String()}, </del> <ins> serviceResolver: serviceResolver, </ins> proxyTransport:  &http.Transport{}, } handler.contextMapper = &fakeRequestContextMapper{user: tc.user}

https://k8s- https://k8s- https://k8s- https://k8s- https://k8s- ... A lot of them /cc
/assign
Still see this failure after is merged, although less frequently: https://k8s- https://k8s- Reopen.
Looks like the client doesn't differentiate between 500 and 503 here: It should. Will open a fix shortly
opened
fix merged, will monitor https://k8s-
Thanks! :)
haven't seen this in the 12 hours since the fix merged, was seeing it every 2-3 hours before. /close


Question: }) } } <ins> func TestConverterMutatesInput(t *testing.T) { testCRD := apiextensionsv1.CustomResourceDefinition{ Spec: apiextensionsv1.CustomResourceDefinitionSpec{ Conversion: &apiextensionsv1.CustomResourceConversion{ Strategy: apiextensionsv1.NoneConverter, }, Group: "test.k8s.io", Versions: []apiextensionsv1.CustomResourceDefinitionVersion{ { Name:   "v1alpha1", Served: true, }, { Name:   "v1alpha2", Served: true, }, }, }, } safeConverter, _, err := NewDelegatingConverter(&testCRD, &inputMutatingConverter{}) if err != nil { t.Fatalf("Cannot create converter: %v", err) } input := &unstructured.UnstructuredList{ Object: map[string]interface{}{ "apiVersion": "test.k8s.io/v1alpha1", }, Items: []unstructured.Unstructured{ { Object: map[string]interface{}{ "apiVersion": "test.k8s.io/v1alpha1", "metadata": map[string]interface{}{ "name": "item1", }, }, }, { Object: map[string]interface{}{ "apiVersion": "test.k8s.io/v1alpha1", "metadata": map[string]interface{}{ "name": "item2", }, }, }, }, } toVersion, _ := schema.ParseGroupVersion("test.k8s.io/v1alpha2") toVersions := schema.GroupVersions{toVersion} converted, err := safeConverter.ConvertToVersion(input, toVersions) if err != nil { t.Fatalf("unexpected error: %v", err) } convertedList := converted.(*unstructured.UnstructuredList) if e, a := 2, len(convertedList.Items); e != a { t.Fatalf("length: expected %d, got %d", e, a) } } type inputMutatingConverter struct{} func (i *inputMutatingConverter) Convert(in *unstructured.UnstructuredList, targetGVK schema.GroupVersion) (*unstructured.UnstructuredList, error) { out := &unstructured.UnstructuredList{} for _, obj := range in.Items { u := obj.DeepCopy() u.SetAPIVersion(targetGVK.String()) out.Items = append(out.Items, *u) } in.Items = nil return out, nil } </ins>

If a CR converter is wired in and it modifies the input list, the delegating CR converter does not protect against this. A converter cannot effect the input list Not really possible externally - it's a coding issue that the current converters don't hit. No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /assign
/triage accepted


Question: testJSONPathSortOutput(randomPrintOrderTests, t) } <ins> func TestNestedRanges(t *testing.T) { var input = []byte(`{ "items": [ { "metadata": { "name": "pod1" }, "spec": { "containers": [ { "name": "foo", "another": [ { "name": "value1" }, { "name": "value2" } ] }, { "name": "bar", "another": [ { "name": "value1" }, { "name": "value2" } ] } ] } }, { "metadata": { "name": "pod2" }, "spec": { "containers": [ { "name": "baz", "another": [ { "name": "value1" }, { "name": "value2" } ] } ] } } ] }`) var data interface{} err := json.Unmarshal(input, &data) if err != nil { t.Error(err) } testJSONPath( []jsonpathTest{ { "nested range with a trailing newline", `{range .items[*]}` + `{.metadata.name}` + `{":"}` + `{range @.spec.containers[*]}` + `{.name}` + `{","}` + `{end}` + `{"+"}` + `{end}`, data, "pod1:foo,bar,+pod2:baz,+", false, }, }, false, t, ) testJSONPath( []jsonpathTest{ { "nested range with a trailing character within another nested range with a trailing newline", `{range .items[*]}` + `{.metadata.name}` + `{"~"}` + `{range @.spec.containers[*]}` + `{.name}` + `{":"}` + `{range @.another[*]}` + `{.name}` + `{","}` + `{end}` + `{"+"}` + `{end}` + `{"#"}` + `{end}`, data, "pod1~foo:value1,value2,+bar:value1,value2,+#pod2~baz:value1,value2,+#", false, }, }, false, t, ) testJSONPath( []jsonpathTest{ { "two nested ranges at the same level with a trailing newline", `{range .items[*]}` + `{.metadata.name}` + `{"t"}` + `{range @.spec.containers[*]}` + `{.name}` + `{" "}` + `{end}` + `{"t"}` + `{range @.spec.containers[*]}` + `{.name}` + `{" "}` + `{end}` + `{"n"}` + `{end}`, data, "pod1tfoo bar tfoo bar npod2tbaz tbaz n", false, }, }, false, t, ) } </ins> func TestFilterPartialMatchesSometimesMissingAnnotations(t *testing.T) { // for https://issues.k8s.io/45546 var input = []byte(`{

<!-- 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: (or in my instance) with does not correctly handle nested range statements. For example, one would expect that the following: would result in a list being output similar to this: but instead, results in a list being output like this: What you expected to happen: Nested range statements complete in the order in which they are specified in jsonpath query. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.11.0 Cloud provider or hardware configuration: OpenShift 3.11.141 on vSphere 6.5 OS (e.g: ): RHEL 7.7 Kernel (e.g. ): 3.10.0 Install tools:
/sig cli
/area kubectl
/assign
/sig api-machinery
/remove-sig cli
/remove-area cli /area api
Those labels are not set on the issue: <detailsIn response to : /remove-area cli /area api 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-area kubectl


Question: EXTERNAL_HOSTNAME=${EXTERNAL_HOSTNAME:-localhost} KUBELET_HOST=${KUBELET_HOST:-"127.0.0.1"} <ins> KUBELET_RESOLV_CONF=${KUBELET_RESOLV_CONF:-"/etc/resolv.conf"} </ins> # By default only allow CORS for requests on localhost API_CORS_ALLOWED_ORIGINS=${API_CORS_ALLOWED_ORIGINS:-/127.0.0.1(:[0-9]+)?$,/localhost(:[0-9]+)?$} KUBELET_PORT=${KUBELET_PORT:-10250}

changed from "kube-dns" to "core-dns". "core-dns" is failing for me on Debian Buster: works when I use . "core-dns" should work. Perhaps related to this? Kubernetes version (use ): current master () OS (e.g: ): Debian Buster Kernel (e.g. ): 5.5.0-0.bpo.2-amd64 /cc
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
provides a description of the error, causes, and workarounds. Typically this is due to a local dns resolver installed on the host. Solution is to configure kubelet to use a different (more detail in link).
That mirrors what I found through the issue. Needs to be fixed in then.
/sig testing /cc
/cc
I think we have to parameterize this
I think the safer way is to configure kublet to send the correct to all “default” dns policy pods, not just fix in coredns.
Doh, right :)


Question: cd "${KUBE_ROOT}" # build ginkgo and e2e.test <del> hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </del> <ins> # # Set DBG=1 to build with embedded filenames as filenames rather than # module-relative names (e.g. /src/kube/foo/bar.go vs. # k8s.io/kubernetes/foo/bar.go).  These names are used by gingko in # `--spec-dump` which is consumed later in conformance verification. DBG=1 hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </ins> # dump spec ./_output/bin/ginkgo --dry-run=true --focus='[Conformance]' ./_output/bin/e2e.test -- --spec-dump "${KUBE_ROOT}/_output/specsummaries.json" > /dev/null

While working on for , I found that our kubernetes1.24 package stopped to produce bit-identical results on 2 fresh builds. The first chunk is likely just the hash of the remainder, so can be ignored. The other chunks indicate that a random build temporary path is used for Sources should be able to reproduce bit-identical binaries e.g. for SLSA level4 On Debian or openSUSE do No response <detailsWARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version. Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-05-05T00:00:00Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"} Kustomize Version: v4.5.4 console $ cat /etc/os-release $ uname -a Linux bmwiedemann-factory 5.18.6-1-default SMP PREEMPTDYNAMIC Thu Jun 23 05:46:18 UTC 2022 () x8664 x8664 x86_64 GNU/Linux </details<detailsgo1.18 </details<details</details<details</details
/sig release /area build-release
can you please post a link to the full logs from the build?
any news on this? Haven't heard from (context: we worked to fix this a couple of times in )
Unfortunately not, is this something we can fix on the OBS side? If the go build timestamp () is the main issue here then we can approach a fix in our build pipeline.
It would be good if would not be embedded in the first place. It might be possible to replace it somehow in our builds, but all other people wanting reproducible builds, would need to replicate that.
full logs from the build: from kubernetes-1.24.3 built 2022-08-18
can you please try setting GOCACHE=off when you run the build? I am suspecting that the temp directory is being generated here: (or add an export in for that env var)
I to but still got these diffs.


Question: cd "${KUBE_ROOT}" # build ginkgo and e2e.test <del> hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </del> <ins> # # Set DBG=1 to build with embedded filenames as filenames rather than # module-relative names (e.g. /src/kube/foo/bar.go vs. # k8s.io/kubernetes/foo/bar.go).  These names are used by gingko in # `--spec-dump` which is consumed later in conformance verification. DBG=1 hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </ins> # dump spec ./_output/bin/ginkgo --dry-run=true --focus='[Conformance]' ./_output/bin/e2e.test -- --spec-dump "${KUBE_ROOT}/_output/specsummaries.json" > /dev/null

So i built golang from source, peppered it with changes to track down where this is getting created and found that it is coming from: I don't know yet how to fix it. will dig more when i can (travelling for the next few days)
Would it work to override the , I see that they use the : Ref: https://reproducible- Edit: Probably not, we may make it configurable in golang :thinking:
this is so tricky :( will dig more when i get back from my event this week
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages 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: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned".


Question: cd "${KUBE_ROOT}" # build ginkgo and e2e.test <del> hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </del> <ins> # # Set DBG=1 to build with embedded filenames as filenames rather than # module-relative names (e.g. /src/kube/foo/bar.go vs. # k8s.io/kubernetes/foo/bar.go).  These names are used by gingko in # `--spec-dump` which is consumed later in conformance verification. DBG=1 hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </ins> # dump spec ./_output/bin/ginkgo --dry-run=true --focus='[Conformance]' ./_output/bin/e2e.test -- --spec-dump "${KUBE_ROOT}/_output/specsummaries.json" > /dev/null

<detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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
This is still relevant even with 1.27. It might be worth revisiting this issue again. /reopen /triage accepted
Reopened this issue. <detailsIn response to : This is still relevant even with 1.27. It might be worth revisiting this issue again. /reopen /triage accepted 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-lifecycle rotten
latest run -
I found that our package has the same issue, so it probably it is a toolchain issue in golang - and much faster to debug outside of the slow kubernetes build. =filed
AIUI, the conclusion by the golang people seems to be that commit is not the right approach and one should use with the go call instead. Not sure how that interacts with other parts of your build.
cc (please see referenced commit above!)
I see. I inherited the gcflags before so I plead innocence. It seems plausible to change it from to - I don't know when I will have time to look at that, though.


Question: cd "${KUBE_ROOT}" # build ginkgo and e2e.test <del> hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </del> <ins> # # Set DBG=1 to build with embedded filenames as filenames rather than # module-relative names (e.g. /src/kube/foo/bar.go vs. # k8s.io/kubernetes/foo/bar.go).  These names are used by gingko in # `--spec-dump` which is consumed later in conformance verification. DBG=1 hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </ins> # dump spec ./_output/bin/ginkgo --dry-run=true --focus='[Conformance]' ./_output/bin/e2e.test -- --spec-dump "${KUBE_ROOT}/_output/specsummaries.json" > /dev/null

My patch doesn't seem to fix the whole problem: thockin-glaptop4 kubernetes buildtrimpath /$ make kubelet +++ [1114 19:10:12] Building go targets for linux/amd64 (non-static) thockin-glaptop4 kubernetes buildtrimpath /$ md5sum output/bin/kubelet output/bin/kubelet thockin-glaptop4 kubernetes buildtrimpath /$ make kubelet +++ [1114 19:12:40] Building go targets for linux/amd64 (non-static) thockin-glaptop4 kubernetes buildtrimpath /$ md5sum output/bin/kubelet output/bin/kubelet thockin-glaptop4 kubernetes build_trimpath /$
diff --- a 2023-11-14 19:13:45. -0800 +++ b 2023-11-14 19:13:56. -0800 -1,4 +1,4 -38rZHdQckYF9EEzmndR/BAXOwzCcq0Mk1UHT62ha/QLiRgXP4oojWh3oWP9/TWG7KW90IL8vKt1UOEPR +LeLArvl7sgWAd55ROKN2/BAXOwzCcq0Mk1UHT62ha/QLiRgXP4oojWh3oWP9/cYb5ZGQwa6js077YiAvK /lib64/ld-linux-x86- AUATUSH []AA] -,8 +,8 go1.21.3 runtime/cgo: call frame too large -2023-11-15T03:12:40Z -2023-11-15T03:12:40Z +2023-11-15T03:13:47Z +2023-11-15T03:13:47Z pthreadcreate failed: %s bad stack bounds: lo=%p hi=%p expand 32-byte kexpand 32-byte k
That seems unrelated. I tested with and it made our openSUSE package fully reproducible. Your diff contains a timestamp - maybe would get rid of that. The top part of the diff is just the go build-id hash of the remainder and can be ignored.


Question: cd "${KUBE_ROOT}" # build ginkgo and e2e.test <del> hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </del> <ins> # # Set DBG=1 to build with embedded filenames as filenames rather than # module-relative names (e.g. /src/kube/foo/bar.go vs. # k8s.io/kubernetes/foo/bar.go).  These names are used by gingko in # `--spec-dump` which is consumed later in conformance verification. DBG=1 hack/make-rules/build.sh github.com/onsi/ginkgo/v2/ginkgo test/e2e/e2e.test </ins> # dump spec ./_output/bin/ginkgo --dry-run=true --focus='[Conformance]' ./_output/bin/e2e.test -- --spec-dump "${KUBE_ROOT}/_output/specsummaries.json" > /dev/null

Thanks for confirming
Will there be backports to 1.24++ ? I found it applies cleanly to 1.26++ and works with some small tweaks in 1.24 and 1.25. If not, I'd submit the patch for our openSUSE packages.
1.24 and 1.25 reached EOL and we don't support these branches any longer. We can cherry-pick this to 1.26+ if folks ( agree
Cherry-picks: 1.29 1.28 1.27 1.26


Question: testName:           "node exists by provider id", existsByProviderID: true, providerIDErr:      nil, <del> existsByNodeName:   false, </del> <ins> hasInstanceID:      true, </ins> nodeNameErr:        errors.New("unimplemented"), expectedCalls:      []string{"instance-exists-by-provider-id"}, <ins> expectedNodeExists: true, </ins> node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Name: "node0",

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The change here removes exiternal id, but the call to instance id was not made used at all, it will always return false. At this time no node was able to register What you expected to happen: ProviderId was used in check How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment:
similar to are you using --cloud-provider in your controller manager? are you also setting it on your kubelet?
I'm using acs-engine to deploy the cluster. Config is as following: I've proposed a fix. PTAL
/sig cluster-lifecycle


<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Unknown yet. Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated /sig scheduling /help
Can I give it a try?
Sure, feel free to take it. /assign ahmad-diaa /remove-help
I keep trying to get it fail locally by running the following command: but it never does, am I doing something wrong? Is there something else that I should be doing and would be more helpful?
Sometimes the flake is hard to reproduce in local env. You may have to read the error log of the flakes thoroughly to get some clues. BTW: you can also run the test multiple times using the directive:
After looking through the logs I came up with some information that might be useful As far as I understand, the reason for the flake is the of the medium priority pod not being cleared That is because the update request for removing returns the following error: So my current guess is that might be outdated in some cases As I am not really familiar with the logic, I would like to know whether or not those are valid points so that I could dig deeper. What do you think?
If that's the case, you can set here: You can raise a PR and manually try for ~20 times to see you can reproduce the flake.
found another issue tracking this too. it seems it has been flaky for a while.
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution.
This sometimes happens. But we usually take the first PR unless it's clearly worked by someone. In terms of which style to resolve the Conflict error, I'm asking here:
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution. No worries, I haven't started implementing yet and your PR seems to be following the correct approach as well according to this:


<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: [TODO] Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig node These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry.


Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: /sig scheduling
/assign
any progress on this one?
I was working on it and tried to find the root cause. I will give my solution within this week
Another one
Still happening cc
/assign
/close dupe
Closing this issue. <detailsIn response to : /close dupe 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


Question: return mc.Observe(err) } <del> err = gce.waitForZoneOp(createOp, zone, mc) </del> <ins> err = gce.manager.WaitForZoneOp(createOp, zone, mc) </ins> if isGCEError(err, "alreadyExists") { glog.Warningf("GCE PD %q already exists, reusing", name) return nil

Unit tests are needed for the GCE cloud provider disk interface.
Assigned to
/assign
GitHub didn't allow me to assign the following users: verult. Note that only can be assigned.. <detailsIn response to : /assign 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. I understand the commands that are listed . </details


Question: if pod.Status.Phase == api.PodFailed || pod.Status.Phase == api.PodSucceeded { period = 0 } <ins> if period < 0 { period = 1 } </ins> // ensure the options and the pod are in sync options.GracePeriodSeconds = &period return true

<!-- 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: Some k8s client tried to evict a pod by setting negative value for deletionGracePeriodSeconds. But all eventual delete calls (and force-delete calls) made by kubelet, pod-garbage-collector, etc were not able to delete that pod, because apiserver doesnt allow deletionGracePeriodSeconds to be increased once it is set. So force-delete (which set it to 0) doesn't take effect when it's already negative. Not even kubectl is able to call delete with negative grace-period. But curl with an even more negative grace-period value worked. What you expected to happen: force-delete works. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I think the issue is in the code below As the comment suggest, in phase 1, the was set to a negative value (meaning was in the past), and in phase 2, has to be set even lower, otherwise, it will be considered as pending graceful deletion and not performing the immediate delete. I think there're two possible fixes. not allowing setting in the past ( should be non-negative). In that case, we could convert to 0 if negative. that could be set in the past. In that case, in phase 2, we treat negative value of the same as 0, and allow immediate delete. Thoughts? Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig api-machinery 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
/cc /triage accepted
No component in the system should ever treat the timestamp of DeletionTimestamp as authoritative.


Question: if pod.Status.Phase == api.PodFailed || pod.Status.Phase == api.PodSucceeded { period = 0 } <ins> if period < 0 { period = 1 } </ins> // ensure the options and the pod are in sync options.GracePeriodSeconds = &period return true

In Kube, components are required to calculate the time period from when they observe the event in their local clock (i.e. 30s from now), not use the deletion timestamp. A negative value of deletion grace period should be rejected by the apiserver as an invalid value (bad request / invalid field).
attempts to take a missing or positive deletion grace period negative should be rejected, I agree. if a negative value is already persisted, I'd be inclined to allow a negative value in an update and clip to 0
As I mentioned in the PR, eviction is passing negatives through to the store: In kubectl, we specify the default value for GracePeriod is -1. In the case of delete, we simply don't set the value in the deleteOptions we send to the API. In the case of eviction, we send the -1 value, and that gets passed along to the store.
I don't see the -1 getting sent to the eviction API. It looks like values < 0 result in a nil value being sent to the API: I would not expect the API to accept a negative value as-is.
Looks like you are correct. Do the deletionOptions go through their own validation or through some kind of validation for the evict API? The original bug report mentions 'evict' though it's not clear if the eviction API was used or not.
ValidateDeleteOptions is called inside pod deletion, but did not check that the field was non-negative. I don't see any eviction-specific validation.
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-contributor-experience at . /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-contributor-experience at . /lifecycle rotten
/lifecycle rotten
Im investigating the and . Surprisingly see you here...


Question: - Add validation code that checks request <= limit, and validation test cases (api/validation/validation.go) Scheduler Changes <del> - Use requests instead of limits in CheckPodsExceedingCapacity and PodFitsResources (scheduler/algorithm/predicates.go) </del> <ins> - Predicates: Use requests instead of limits in CheckPodsExceedingCapacity and PodFitsResources (scheduler/algorithm/predicates/predicates.go) - Priorities: Use requests instead of limits in LeastRequestedPriority and BalancedResourceAllocation(scheduler/algorithm/priorities/priorities.go)(PR #12718) </ins> Container Manager Changes - Use requests to assign CPU shares for Docker (kubelet/dockertools/container_manager.go)

did which addresses some of them, but turns up a lot more.
Alright, I will do that.


Question: <ins> /* Copyright 2021 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package routes import ( "fmt" "os" "testing" ) func TestPreCheckLogFileNameLength(t *testing.T) { oversizeFileName := fmt.Sprintf("%0256s", "a") normalFileName := fmt.Sprintf("%0255s", "a") // check file with oversize name. if !logFileNameIsTooLong(oversizeFileName) { t.Error("failed to check oversize filename") } // check file with normal name which doesn't exist. if logFileNameIsTooLong(normalFileName) { t.Error("failed to check normal filename") } // check file with normal name which does exist. _, err := os.Create(normalFileName) if err != nil { t.Error("failed to create test file") } defer os.Remove(normalFileName) if logFileNameIsTooLong(normalFileName) { t.Error("failed to check normal filename") } } </ins>

Hello and I were fuzzing the k8s (via ) and found out following bug. Getting logs from unicode logpath via API causes internal server error. The API endpoint is . Response with non-500 HTTP status code We were fuzzing k8s locally via minikube. minukube ca certificates k8s IP address the IP to as access token and export it as request Kubernetes version (use ):Cloud provider or hardware configuration: minikube with virtual-box driver OS (e.g: ): Ubuntu 18.04.5 LTS (bionic) Kernel (e.g. ): Linux pine 4.15.0-140-generic -Ubuntu SMP Fri Mar 19 14:12:35 UTC 2021 x8664 x8664 x86_64 GNU/Linux Install tools: downloaded precompiled binary minikube version: v1.19.0 (commit: )
/sig api-machinery
/assign I will look into it.
thank you , please keep us posted! /triage accepted
For clarity are you saying that the fuzzed URL is valid or invalid UTF-8 (URL-encoded)?
It's valid UTF-8
Actually, according to my test,this bug comes from http.ServeFile which replies to the request with the contents of the named file or directory. When giving too long(On Linux: The maximum length for a file name is 255 bytes. The maximum combined length of both the file name and path name is 4096 bytes.) filename or pathname to http.ServeFile,it will return code 500(file name too long) rather than 404(no such file or directory). And when filename is not that long, unicode path work correctly too. Here is my simple test below: And since /logs is the only place use http.ServeFile, there is no other api has the same problem. ! So I will add a length check before calling http.ServeFile to solve this. Does that sound good to you?
Maybe 400 - bad request would be more suitable response code. But I'm not a maintainer so it's not up to me to decide.
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 .


Question: <ins> /* Copyright 2021 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package routes import ( "fmt" "os" "testing" ) func TestPreCheckLogFileNameLength(t *testing.T) { oversizeFileName := fmt.Sprintf("%0256s", "a") normalFileName := fmt.Sprintf("%0255s", "a") // check file with oversize name. if !logFileNameIsTooLong(oversizeFileName) { t.Error("failed to check oversize filename") } // check file with normal name which doesn't exist. if logFileNameIsTooLong(normalFileName) { t.Error("failed to check normal filename") } // check file with normal name which does exist. _, err := os.Create(normalFileName) if err != nil { t.Error("failed to create test file") } defer os.Remove(normalFileName) if logFileNameIsTooLong(normalFileName) { t.Error("failed to check normal filename") } } </ins>

Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active 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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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


Question: r.MilliCPU = cpu } case v1.ResourceEphemeralStorage: <del> if ephemeralStorage := rQuantity.Value(); ephemeralStorage > r.EphemeralStorage { r.EphemeralStorage = ephemeralStorage </del> <ins> if utilfeature.DefaultFeatureGate.Enabled(features.LocalStorageCapacityIsolation) { if ephemeralStorage := rQuantity.Value(); ephemeralStorage > r.EphemeralStorage { r.EphemeralStorage = ephemeralStorage } </ins> } default: if v1helper.IsScalarResourceName(rName) {

What happened: In a v1.18 cluster with the LocalStorageCapacityIsolation feature gate disabled setting an ephemeral-storage request or limit causes the pod to be unschedulable: If the ephemeral-storage request is removed the pod is scheduled. This behavior exists in v1.19 and a recent v1.20 build. What you expected to happen: In previous releases such pods are scheduled. I expect that any ephemeral-storage limit is not enforced. How to reproduce it (as minimally and precisely as possible): Disable the LocalStorageCapacityIsolation feature guide by adding to the kube-scheduler. Create a pod like this: Anything else we need to know?: The problem was originally seen after moving from IBM Cloud Red Hat OpenShift v4.4 to v4.5. Pods that worked in 4.4 (Kubernetes v1.17) remained in a Pending state in OpenShift v4.5 (Kubernetes 1.18). We discovered that the IBM Cloud OpenShift service has the LocalStorageCapacityIsolation feature-gate disabled while Red Hat has enabled the feature. We then replicated the behavior with a plain Kubernetes cluster. Environment: Kubernetes version (use ): v1.18.10, v1.19.3, v1.20.0 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 sig-scheduling
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-scheduling 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 scheduling
I can confirm it's a bug. Will work on it.


Question: r.MilliCPU = cpu } case v1.ResourceEphemeralStorage: <del> if ephemeralStorage := rQuantity.Value(); ephemeralStorage > r.EphemeralStorage { r.EphemeralStorage = ephemeralStorage </del> <ins> if utilfeature.DefaultFeatureGate.Enabled(features.LocalStorageCapacityIsolation) { if ephemeralStorage := rQuantity.Value(); ephemeralStorage > r.EphemeralStorage { r.EphemeralStorage = ephemeralStorage } </ins> } default: if v1helper.IsScalarResourceName(rName) {

/assign
Clarifying the recreate steps: I disabled the LocalStorageCapacityIsolation feature guide by adding to the kube-scheduler since this behavior seems to be within the scheduler.
Thanks for confirming!
This bug has been fixed in master branch, and will be backported to [1.18] and [1.19] soon. [1.18]: [1.19]:


Question: } } <ins> func TestAllocateNextFC(t *testing.T) { _, cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } t.Logf("CIDR %s", cidr) r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("wrong ip %s : %v", ip, err) } t.Log(ip.String()) } </ins> func BenchmarkIPAllocatorAllocateNextIPv4Size1048574(b *testing.B) { _, cidr, err := netutils.ParseCIDRSloppy("10.0.0.0/12") if err != nil {

We ran into an issue with an old version of k8s 1.18 that we were running where subnet for cluster IP is given as . The control plane comes up just fine but then when you try to create a k8s service, it fails due to a broken behavior with the IP Allocator Since this is not really a supported version of the k8s, I went around digging up a bit more to see what is the regular behavior and found this to be very inconsistent across a few release branches. bash go test -timeout 30m -run ^TestAllocateNextFC$ -v === RUN TestAllocateNextFC ? --- PASS: TestAllocateNextFC (0.00s) PASS ok 0.566s go func TestAllocateNextFC(t *testing.T) { , cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } // Need to be replaced with the suitable handler for that version of the branch r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("%s", err.Error()) } fmt.Println(ip.String()) } Add the above Test case under the IP allocator test case No response_ <detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details
/sig network /assign /kind bug
Thanks for helping me with this issue.
/triage accepted /assign


Question: } // create target_dir before call to NodePublish <del> if err := os.MkdirAll(dir, 0750); err != nil && !corruptedDir { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", dir, err)) </del> <ins> parentDir := filepath.Dir(dir) if err := os.MkdirAll(parentDir, 0750); err != nil { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", parentDir, err)) </ins> } <del> klog.V(4).Info(log("created target path successfully [%s]", dir)) </del> <ins> klog.V(4).Info(log("created target path successfully [%s]", parentDir)) </ins> nodePublishSecrets = map[string]string{} if secretRef != nil {

What happened: A custom CSI driver implementing returns a failure response, indicating that it did not complete its intended steps to prepare the volume for the mounting pod. Let's say that these steps involve a filesystem at the target directory, data from a service, and that data to a set of files in the mounted filesystem. If the first filesystem mounting step succeeds, but either of the subsequent two steps fail, the volume is still not ready for use by the pod. However, if this CSI driver returns a failure response, and the CSI mounter comes back and, before invoking the RPC again, it finds a filesystem already mounted at the target directory, , and ceases further calls to to allow the CSI driver to try again. What you expected to happen: If a CSI driver returns a failure response to a RPC, Kubernetes should honor that declaration of failure and invoke the RPC again, disallowing the mounting pod from starting until this RPC succeeds. Even though it's possible to partially work around the current behavior by having the driver mount the filesystem as late as possible, and then attempting to unmount it if fails to populate the volume with its intended data, doing so makes writing drivers more complicated and forces them to do extra work. How to reproduce it (as minimally and precisely as possible): In a CSI driver (even one that serves just ephemeral, inline volumes), implement to mount a filesystem at the target path, then return a failure response. Confirm that Kubernetes does not invoke again, because there's now a filesystem mounted at the target path. Anything else we need to know?: This topic came up for discussion in the "Kubernetes" Slack team. There, helped investigate this complaint, and to discuss changing this behavior. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS EC2 OS (e.g: ):Kernel (e.g. ):Install tools: kubeadm Others: csi-node-driver-registrar container image tag: v1.0.2
/sig storage
While the plugin should try to clean up as much as possible, I agree that kubelet should not be assuming that if there's a mount point, the publish is successful. NodePublish is supposed to be idempotent so it should theoretically be safe to call it when it's already mounted, although there is the possibility that plugins may have written against the K8s behavior.


Question: } // create target_dir before call to NodePublish <del> if err := os.MkdirAll(dir, 0750); err != nil && !corruptedDir { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", dir, err)) </del> <ins> parentDir := filepath.Dir(dir) if err := os.MkdirAll(parentDir, 0750); err != nil { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", parentDir, err)) </ins> } <del> klog.V(4).Info(log("created target path successfully [%s]", dir)) </del> <ins> klog.V(4).Info(log("created target path successfully [%s]", parentDir)) </ins> nodePublishSecrets = map[string]string{} if secretRef != nil {

For the mount point checking here before calling NodePublishVolume, I am wondering it is just for performance optimization, or it has other purposes. Have concern about some drivers might depend on this check if they are not implemented with idenpotency.
Those drivers would be operating in violation of the specification. I'd prefer that we don't penalize already conforming and yet-to-be written drivers in order to accommodate these existing drivers—if they even exist.
More fallout in last night's testing: I introduced a bug into my driver that caused it to panic during ("Writing that data to a set of files in the mounted filesystem"). My handler function is set up to unmount a successfully mounted volume via if it doesn't complete steps 2 and 3 above, in order to deal with this issue's principal complaint. My driver container would crash due to this panic. The kubelet would call on my driver twice, it would crash twice, but the pod still started running. I'm not yet sure whether or not the filesystem got unmounted successfully via the on the first call, but somehow the pod started despite my handler function never completing successfully. I'm going to try to get some more debugging time on this later today to see if I can figure out what the kubelet was doing there.
Studying my code more, I see that my function only unmounted the mounted directory when the containing handler function was returning an error. When unwinding due to a panic, the named return value of type I was inspecting was still nil. Revising the criteria in that function covers both failure reasons (returning an and unwinding due to a panic). Regardless, this further underscores the problem: If a driver makes it as far as mounting a filesystem at the target directory, but fails afterward—including the process crashing and never responding positively to the RPC—the mounting pod will start. That's likely to then cause the pod to fail, for lack of the files it expected to find mounted.
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
Issues go stale after 90d of inactivity.


Question: } // create target_dir before call to NodePublish <del> if err := os.MkdirAll(dir, 0750); err != nil && !corruptedDir { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", dir, err)) </del> <ins> parentDir := filepath.Dir(dir) if err := os.MkdirAll(parentDir, 0750); err != nil { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", parentDir, err)) </ins> } <del> klog.V(4).Info(log("created target path successfully [%s]", dir)) </del> <ins> klog.V(4).Info(log("created target path successfully [%s]", parentDir)) </ins> nodePublishSecrets = map[string]string{} if secretRef != nil {

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
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


Question: util-linux  socat  curl  <ins> git  </ins> && DEBIAN_FRONTEND=noninteractive apt-get autoremove -y  && DEBIAN_FRONTEND=noninteractive apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

I'm running Kubernetes under Docker (following guide). I tried to set up an RC that would run a registry:2 container and attach a gitRepo volume with the SSL certs I want to use. When I run it though, I get this error: If k8s supports git repositories as volumes though, it feels like the executable should be included in the container.
k8s supports git repositories as volumes but it's an optional feature that not everyone wants, so it would not be appropriate to require/include the git executable. This is similar to how k8s supports nfs volumes, but we don't require you to run the kubelet on an os with nfs kernel support, because not everyone wants it.
Hmm. Okay, that makes sense. Would it be feasible to create tags for those containers that have git?
I think I misunderstood the request. I think it's actually reasonable to add git to hyperkube, since afaict, it's only used for single node docker. The Dockerfile is , feel free to send a pr.


Question: import ( "fmt" <ins> "strings" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

The e2e test should be relaxed. It currently checks 3 different aspects of the volume mount flag: with do not receive mounts from outside their own mount namespace, nor do mount namespaces outside the container receive mounts created within the container. with receive new mounts from the host OS, the container runtime, and other containers with , but no mount namespaces outside the container receive mounts created within the container. with receive new mounts identical to containers with , but additionally any mounts made by these containers are: propagated to the container runtime where they can be propagated to other containers (related to 2) also propagated to the Host OS The first 3 aspects, up to and including 3.i, are critical for container operation and should still be ensured by an e2e test. This last check, 3.ii., is the part that I believe is overly strict. The current e2e test is too opinionated on the underlying node OS configuration. The requirement of propagation to the host OS precludes administrators or solution providers from modifying the Kubernetes installation to hide these Kubernetes-specific mountpoints, which can be for a variety of reasons: While access to container-specific mounts in Kubernetes (like secrets) today are protected by filesystem permissions, the fact that the locations are visible to unprivileged users via the 'mount' command can provide information which could be used in conjunction with other vulnerabilities to decipher secrets or other protected container mount contents. Locking access to even listing the mountpoints behind the ability to enter the mount namespace (which in turn requires and ) removes one level of potential access to container-specific mounts. These container overlay mounts, secret and configmap mounts, and namespace mounts are all internal implementation details around the way the Kubernetes and the Container Runtime allocate resources to containers. For normal day-to-day operation, there is no need for these special-use mounts to be visible in the host OS's top-level 'mount' or 'findmnt' output. After much investigation and conversation on both the sig-node and sig-storage mailing lists, as well as within Red Hat's OpenShift communities, we have yet to turn up a use case that relies on this container-to-host propagation. In fact, it may be seen as an anti-pattern and run contrary to the container-native way of doing things. Relying on a host OS to interact with a container-owned mountpoint seems suspect.


Question: import ( "fmt" <ins> "strings" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Today systemd's CPU usage is adversely affected by a large number of mountpoints, especially versions released prior to December 2020. This feature of systemd, which scans all /proc/1/mount to invoke udev events for every change suffers from two issues. The first was an inefficiency in systemd’s processing logic. This was fixed in December 2020, and this fix reportedly reduced the systemd mount-scanning-related overhead by 30-50%. The second is a lack of granularity in the events the kernel sends to systemd about mountpoint changes, which necessitates a full rescan of all mountpoints even on a minor change or single mountpoint addition. The kernel change to remedy this seems unlikely to move forward in the near term. (See for more details) For example, a fairly small OpenShift deployment today (which does not yet have the systemd December 2020 fix) has upwards of 400 mountpoints on every node owned by Kubelet, the Container Runtime, and infrastructure containers like OVN or CSI operators. Hiding the container mountpoints reduces the steady-state systemd CPU utilization from ~10% to ~0% on every worker node. On a more heavily loaded system, with 1000’s of container mountpoints, systemd’s usage will cap out at 100% of a single CPU core. Even with the 30-50% reduction in systemd usage expected from the December 2020 fix, having systemd take up as much as 50-70% of a single CPU in the worst-case scenario is a lot of unnecessary overhead. Administrators of other OSes with other host OS services that monitor or process mountpoints indiscriminately would be able to hide these container-specific mountpoints from the OS at large, at their option. With this requirement relaxed, it would be possible to run multiple instances of Kubernetes on a single host without the various mountpoints interfering with one another. There may be other inter-instance difficulties besides the mount namespace, but this does move in that direction without resorting to more complicated solutions like trying to run Kubernetes inside of containers.
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 .


Question: import ( "fmt" <ins> "strings" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig architecture storage /area conformance
I have a proof-of-concept of the relaxed test as well as some more and an OpenShift-based proof-of-concept of an actual implementation with the container mounts in their own namespace
/sig node
There's still a number of other issues, no? Is this a real motivation / use-case? There are other difficulties. Most of the difficulties with running Kubernetes inside containers are just the difficulties in sharing a kernel / host OS, which aren't related to this at all. The security and performance angles seem relevant, in any case.
Update: I mistakenly referred to this as a "conformance test" - Turns out it is not in fact a conformance test; just an e2e test :) Edited the original post to be more correct in this respect.
/remove-area conformance /area test
Fair point. I this (intentionally vague) section since some conversation on the sig-node mailing list with folks working on KIND suggested this may align with their goals in some way I'm not entirely clear on.
A good next step on this issue is to open a PR to the related e2e tests that documents why the tests are not good candidates for future inclusion in conformance. Is that something you can assist with ?
I have a branch that relaxes the test so it works in the current environment and a separated mount namespace environment... Can you explain a bit more what you mean about documenting this? Where would that kind of documentation go?


Question: } func createVolumeConfigMap(config *localTestConfig) { <del> mountConfig := struct { HostDir string `json:"hostDir"` }{ HostDir: path.Join(hostBase, discoveryDir), </del> <ins> // MountConfig and ProvisionerConfiguration from // https://github.com/kubernetes-incubator/external-storage/blob/master/local-volume/provisioner/pkg/common/common.go type MountConfig struct { // The hostpath directory HostDir string `json:"hostDir" yaml:"hostDir"` </ins> } <del> data, err := json.Marshal(&mountConfig) </del> <ins> type ProvisionerConfiguration struct { // StorageClassConfig defines configuration of Provisioner's storage classes StorageClassConfig map[string]MountConfig `json:"storageClassMap" yaml:"storageClassMap"` } var provisionerConfig ProvisionerConfiguration provisionerConfig.StorageClassConfig = map[string]MountConfig{ config.scName: { HostDir: path.Join(hostBase, discoveryDir), }, } data, err := yaml.Marshal(&provisionerConfig.StorageClassConfig) </ins> Expect(err).NotTo(HaveOccurred()) configMap := v1.ConfigMap{

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The local-volume bootstrapper/provisioner configuration format changed in kubernetes-incubator/external-storage, and its related e2e tests will fail when the provisioner & bootstrapper images are updated to v2.0.0. What you expected to happen: I'd expect the e2e tests to continue to work properly with the new version of the provisioner and boostrapper. How to reproduce it (as minimally and precisely as possible): Update local-volume provisioner and boostrapper images to v2.0.0, and then the provisioner e2e test will fail.
/sig storage
/assign


Question: return } // Node that isn't present according to the cloud provider shouldn't have its address updated <del> exists, err := ensureNodeExistsByProviderIDOrInstanceID(instances, node) </del> <ins> exists, err := ensureNodeExistsByProviderID(instances, node) </ins> if err != nil { // Continue to update node address when not sure the node is not exists glog.Errorf("%v", err)

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The change here removes exiternal id, but the call to instance id was not made used at all, it will always return false. At this time no node was able to register What you expected to happen: ProviderId was used in check How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment:
similar to are you using --cloud-provider in your controller manager? are you also setting it on your kubelet?
I'm using acs-engine to deploy the cluster. Config is as following: I've proposed a fix. PTAL
/sig cluster-lifecycle


Question: touch /tmp/ready touch /tmp/liveness <del> while true; do </del> <ins> while true; do </ins> echo "hello" sleep 10 done

Tests in are using image for gRPC probe tests: should not be restarted with a GRPC liveness probe should be restarted with a GRPC liveness probe We should use image for these tests as it is much smaller size. /sig node /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue KEP:
This request has been marked as suitable for new contributors. 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 : Tests in are using image for gRPC probe tests: /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue 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
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Tests in are using image for gRPC probe tests: /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue 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
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
Hi can I work on this issue? I'm new to Kubernetes and want to contribute!
Should I change to in this file?
Yes.


Question: touch /tmp/ready touch /tmp/liveness <del> while true; do </del> <ins> while true; do </ins> echo "hello" sleep 10 done

Also pass proper parameters to agnhost to enable gRPC endpoint, change ports, and run tests to ensure that this worked.
Thanks for your reply! Will let you know if I have more questions as I work
/assign
/assign


Question: } if klog.V(2).Enabled() { <del> klog.InfoS("Using component config", "config", buf.String()) </del> <ins> klog.Info("Using component config", "n-------------------------Configuration File Contents Start Here---------------------- n", buf.String(), "n------------------------------------Configuration File Contents End Here---------------------------------n") </ins> } if len(fileName) > 0 {

When running the scheduler at or greater, the processed component config may be logged as a single line with newline characters inserted, like so: config should always be readable and formatted to an easily copied/parsed format, like: Not sure how often this happens, need to try reproducing ref and Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig scheduling
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
The problem has been reproduced. Here are the steps : Steps to Reproduce: kubeadm a pod network runtime, ( I used calico in my case). to reporter's kube-scheduler config yaml, here is another one. apiVersion: clientConnection: acceptContentTypes: "" burst: 100 contentType: application/vnd.kubernetes.protobuf kubeconfig: qps: 50 enableContentionProfiling: true enableProfiling: true healthzBindAddress: "" kind: KubeSchedulerConfiguration leaderElection: leaderElect: true leaseDuration: 15s renewDeadline: 10s resourceLock: leases resourceName: kube-scheduler resourceNamespace: kube-system retryPeriod: 2s metricsBindAddress: "" parallelism: 16 percentageOfNodesoScore: 0 podInitialBackoffSeconds: 1 podMaxBackoffSeconds: 10 profiles: pluginConfig: args: apiVersion: kind: NodeAffinityArgs name: NodeAffinity args: run the kube-scheduler command with an unassigned ip address that your control-plane can bind to: -scheduler --config scheduler- --bind-address "172.18.56.64" -v 5 Here, v can be anything greater than 3. the config file will have n characters in it, whereas it should have been formatted correctly. W1012 19:21:54. ] No authorization-kubeconfig provided, so SubjectAccessReview of authorization tokens won't work.


Question: } if klog.V(2).Enabled() { <del> klog.InfoS("Using component config", "config", buf.String()) </del> <ins> klog.Info("Using component config", "n-------------------------Configuration File Contents Start Here---------------------- n", buf.String(), "n------------------------------------Configuration File Contents End Here---------------------------------n") </ins> } if len(fileName) > 0 {

I1012 19:21:54. ] "Using component config" config="apiVersion: nclientConnection:n acceptContentTypes: ""n burst: 100n contentType: application/vnd.kubernetes.protobufn kubeconfig: n qps: 50nenableContentionProfiling: truenenableProfiling: truenhealthzBindAddress: ""nkind: KubeSchedulerConfigurationnleaderElection:n leaderElect: truen leaseDuration: 15sn renewDeadline: 10sn resourceLock: leasesn resourceName: kube-schedulern resourceNamespace: kube-systemn retryPeriod: 2snmetricsBindAddress: ""nparallelism: 16npercentageOfNodesToScore: 0npodInitialBackoffSeconds: 1npodMaxBackoffSeconds: 10nprofiles:n- pluginConfig:n - args:n apiVersion: n kind: DefaultPreemptionArgsn minCandidateNodesAbsolute: 100n minCandidateNodesPercentage: 10n name: DefaultPreemptionn - args:n apiVersion: n hardPodAffinityWeight: 1n kind: InterPodAffinityArgsn name: InterPodAffinityn - args:n apiVersion: n kind: NodeAffinityArgsn name: NodeAffinityn - args:n apiVersion: n kind: NodeResourcesBalancedAllocationArgsn resources:n - name: cpun weight: 1n - name: memoryn weight: 1n name: NodeResourcesBalancedAllocationn - args:n apiVersion: n kind: NodeResourcesFitArgsn scoringStrategy:n resources:n - name: cpun weight: 1n - name: memoryn weight: 1n type: LeastAllocatedn name: NodeResourcesFitn - args:n apiVersion: n defaultingType: Systemn kind: PodTopologySpreadArgsn name: PodTopologySpreadn - args:n apiVersion: n bindTimeoutSeconds: 600n kind: VolumeBindingArgsn name: VolumeBindingn plugins:n bind:n enabled:n - name: DefaultBindern weight: 0n filter:n enabled:n - name: NodeUnschedulablen weight: 0n - name: NodeNamen weight: 0n - name: TaintTolerationn weight: 0n


Question: } if klog.V(2).Enabled() { <del> klog.InfoS("Using component config", "config", buf.String()) </del> <ins> klog.Info("Using component config", "n-------------------------Configuration File Contents Start Here---------------------- n", buf.String(), "n------------------------------------Configuration File Contents End Here---------------------------------n") </ins> } if len(fileName) > 0 {

- name: NodeAffinityn weight: 0n - name: NodePortsn weight: 0n - name: NodeResourcesFitn weight: 0n - name: VolumeRestrictionsn weight: 0n - name: EBSLimitsn weight: 0n - name: GCEPDLimitsn weight: 0n - name: NodeVolumeLimitsn weight: 0n - name: AzureDiskLimitsn weight: 0n - name: VolumeBindingn weight: 0n - name: VolumeZonen weight: 0n - name: PodTopologySpreadn weight: 0n - name: InterPodAffinityn weight: 0n permit: {}n postBind: {}n postFilter:n enabled:n - name: DefaultPreemptionn weight: 0n preBind:n enabled:n - name: VolumeBindingn weight: 0n preFilter:n enabled:n - name: NodeResourcesFitn weight: 0n - name: NodePortsn weight: 0n - name: VolumeRestrictionsn weight: 0n - name: PodTopologySpreadn weight: 0n - name: InterPodAffinityn weight: 0n - name: VolumeBindingn weight: 0n - name: NodeAffinityn weight: 0n preScore:n enabled:n - name: InterPodAffinityn weight: 0n - name: PodTopologySpreadn weight: 0n - name: TaintTolerationn weight: 0n - name: NodeAffinityn weight: 0n queueSort:n enabled:n - name: PrioritySortn weight: 0n reserve:n enabled:n - name: VolumeBindingn weight: 0n score:n enabled:n - name: NodeResourcesBalancedAllocationn weight: 1n - name: ImageLocalityn weight: 1n - name: InterPodAffinityn weight: 1n - name: NodeResourcesFitn weight: 1n - name: NodeAffinityn weight: 1n - name: PodTopologySpreadn weight: 2n - name: TaintTolerationn weight: 1n schedulerName: default-schedulern" Will be trying to write a unit-test for the same.


Question: } if klog.V(2).Enabled() { <del> klog.InfoS("Using component config", "config", buf.String()) </del> <ins> klog.Info("Using component config", "n-------------------------Configuration File Contents Start Here---------------------- n", buf.String(), "n------------------------------------Configuration File Contents End Here---------------------------------n") </ins> } if len(fileName) > 0 {

Awesome, thank you If you want to open a WIP PR to address the changes, we can start reviewing those while you work on the unit test in the same PR.
Hi Sorry for the super late reply! Was working on other stuff. I can open a PR to fix the issue. i have fixed the actual issue and now the logs format correctly. I am just super confused with how to write a test case to verify this. I went through the unit test framework, and couldn't figure out to write a unit test cases using the go libraries that kube provides. I will write now set up the WIP PR.
thanks! a test case might not be totally necessary, since this is just a change to logging, but if you open up your PR we can see how you fixed it and that might help show how we can add a test around your fix
This is the logging output after the fix: be-system, so request-header client certificate authentication won't work. W1108 05:15:16. 8731 ] No authorization-kubeconfig provided, so SubjectAccessReview of authorization tokens won't work. I1108 05:15:16. 8731 ] Using component configconfigapiVersion: clientConnection: acceptContentTypes: "" burst: 100 contentType: application/vnd.kubernetes.protobuf kubeconfig: qps: 50 enableContentionProfiling: true enableProfiling: true healthzBindAddress: "" kind: KubeSchedulerConfiguration leaderElection: leaderElect: true leaseDuration: 15s renewDeadline: 10s resourceLock: leases resourceName: kube-scheduler resourceNamespace: kube-system retryPeriod: 2s metricsBindAddress: "" parallelism: 16 percentageOfNodesToScore: 0 podInitialBackoffSeconds: 1 podMaxBackoffSeconds: 10 profiles: pluginConfig: args: apiVersion: kind: DefaultPreemptionArgs minCandidateNodesAbsolute: 100 minCandidateNodesPercentage: 10 name: DefaultPreemption args: apiVersion: hardPodAffinityWeight: 1 kind: InterPodAffinityArgs name: InterPodAffinity args: apiVersion: kind: NodeAffinityArgs name: NodeAffinity args: apiVersion: kind: NodeResourcesBalancedAllocationArgs resources: name: cpu weight: 1 name: memory weight: 1 name: NodeResourcesBalancedAllocation args:


Question: } if klog.V(2).Enabled() { <del> klog.InfoS("Using component config", "config", buf.String()) </del> <ins> klog.Info("Using component config", "n-------------------------Configuration File Contents Start Here---------------------- n", buf.String(), "n------------------------------------Configuration File Contents End Here---------------------------------n") </ins> } if len(fileName) > 0 {

apiVersion: kind: NodeResourcesFitArgs scoringStrategy: resources: name: cpu weight: 1 name: memory weight: 1 type: LeastAllocated name: NodeResourcesFit args: apiVersion: defaultingType: System kind: PodTopologySpreadArgs name: PodTopologySpread args: apiVersion: bindTimeoutSeconds: 600 kind: VolumeBindingArgs name: VolumeBinding plugins: bind: enabled: name: DefaultBinder weight: 0 filter: enabled: name: NodeUnschedulable weight: 0 name: NodeName weight: 0 name: TaintToleration weight: 0 name: NodeAffinity weight: 0 name: NodePorts weight: 0 name: NodeResourcesFit weight: 0 name: VolumeRestrictions weight: 0 name: EBSLimits weight: 0 name: GCEPDLimits weight: 0 name: NodeVolumeLimits weight: 0 name: AzureDiskLimits weight: 0 name: VolumeBinding weight: 0 name: VolumeZone weight: 0 name: PodTopologySpread weight: 0 name: InterPodAffinity weight: 0 permit: {} postBind: {} postFilter: enabled: name: DefaultPreemption weight: 0 preBind: enabled: name: VolumeBinding weight: 0 preFilter: enabled: name: NodeResourcesFit weight: 0 name: NodePorts weight: 0 name: VolumeRestrictions weight: 0 name: PodTopologySpread weight: 0 name: InterPodAffinity weight: 0 name: VolumeBinding weight: 0 name: NodeAffinity weight: 0 preScore: enabled: name: InterPodAffinity weight: 0 name: PodTopologySpread weight: 0 name: TaintToleration weight: 0 name: NodeAffinity weight: 0 queueSort: enabled: name: PrioritySort weight: 0 reserve: enabled: name: VolumeBinding weight: 0 score: enabled: name: NodeResourcesBalancedAllocation weight: 1 name: ImageLocality weight: 1 name: InterPodAffinity weight: 1 name: NodeResourcesFit weight: 1 name: NodeAffinity weight: 1 name: PodTopologySpread weight: 2 name: TaintToleration weight: 1 Here, there are no more escape sequences.
cool, if you have time please feel free to open a PR with your changes


Question: 'roles:kubernetes-pool-vsphere': - match: grain - static-routes <ins> 'roles:kubernetes-pool-vagrant': - match: grain - vagrant </ins>

As a sysadmin When using the Vagrant cluster provided And logged in as the vagrant user to the master or minions I would like to be able to call docker commands wihout requiring the 'sudo' prefix. For Fedora =19 and RHEL=7 this can be enabled by adding the vagrant user to the docker group in /etc/groups
This should be trivial, but its tricker to do because of the whole salt configuration process as the docker group is only created on each kubernetes-minion once docker is installed by the salt-minion. To do this properly, we would need a salt state change for this, and new flag in to let you specify additional users that should be in the docker group.


Question: klog.Fatalf("unable to initialize command options: %v", err) } <ins> namedFlagSets := opts.Flags() </ins> cmd := &cobra.Command{ Use: "kube-scheduler", Long: `The Kubernetes scheduler is a control plane process which assigns

ci-kubernetes-e2e-gci-gce-alpha-features kubetest.Up Jul 02 2021, 01:26:42 UTC+0200 /sig release
based on testgrid probably cc <img width="1203" alt="Screen Shot 2021-07-02 at 4 24 25 PM" src="https://user-"
/cc working on it
/assign
the scheduler fails to start with this error: it seems the feature gates from the command line does not take effect in the defaulting phrase, do you know how to fix it?
ah, found there is a cycle here: The scheduler options , but the default config's default values depend on the feature gates options. I think this disables other feature gate controlled logic in the defaulting too:
I tried to fix it by updating the component config after the CLI flags (including the feature gates) are parsed: PTAL
fixed the flake. is back green now.
thanks!


Question: } return &rbdMounter{ <del> rbd:     newRBD("", spec.Name(), img, pool, ro, plugin, &RBDUtil{}), Mon:     mon, Id:      id, Keyring: keyring, Secret:  secret, fsType:  fstype, </del> <ins> rbd:         newRBD("", spec.Name(), img, pool, ro, plugin, &RBDUtil{}), Mon:         mon, Id:          id, Keyring:     keyring, Secret:      secret, fsType:      fstype, accessModes: ams, </ins> }, nil }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When use ceph as storageclass, i set accessModes: ReadOnlyMany, and create pods using the claim, only one pod would be running and the others on different nodes would get stuck on ContainerCreating. But if the pods are all on same node, it works fine. What you expected to happen: Pods on different nodes can mount ceph rbd volume. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.2 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): 3.10.0-327.18.2.el7.x86_64 Kernel (e.g. ): CentOS Linux release 7.2.1511 (Core) Install tools: kubeadm Others:
/sig storage
/assign
, how would this work? For example, how do you put the initial contents of the RBD volume on it if it is in the ReadOnlyMany access mode? How would you use this feature? As a cheap way of sharing files across a Kubernetes cluster? I'm just interested. -ben england
Do we really want to support ? I have the same questions as mentioned above. If we set the PVC AccessMode to , then the field in will need to be set true ? If so, for the first time, in , we will mount the device without formatting, is that intended ? We need to format the device manually before we use it ? /cc FYI: also there is an issue related to this:
We have this same problem for GCE PD, which supports ReadOnlyMany. You need to mount the volume first as RWO, in order to format the filesystem and populate it with data (mounting a read only volume with no data on it seems pointless). Then you have to fully unmount/detach it, and then you can deploy pods using it as ROX. Basically, you can dynamically provision it in RWO to format + populate data. But afterwards, you need to manually create a different PV/PVC for ROX
continuation


Question: UserAgentName = "federation-service-controller" KubeAPIQPS    = 20.0 KubeAPIBurst  = 30 <ins> maxNoOfClusters = 100 </ins> ) type cachedService struct {

<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No 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 ): Environment: Cloud provider or hardware configuration: GCP OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others: What happened: Memory usage of federation-control-manager keeps on increasing to very large size overtime. What you expected to happen: Memory usage is stable How to reproduce it (as minimally and precisely as possible): Register one or more cluster to federation control plane and watch the top output for the federation-control-manager Also can check the pprof, here is the one such output after federation-control-manager is run for an hour. We can see there are around goroutines created in an hour which are leaked and would consume memory. Anything else do we need to know: I do have a fix for the issue and would be happy to submit it, if this issue is accepted.
plz check the issue
feel free to just submit a pull request, we don't really have a concept of an issue being "accepted" :)
This looks like a legitimate bug. could you please clarify what version of the federated service controller you are running? The image path and version of the container, or a git hash of the source should be sufficient.
i am taking the latest code from master branch.


Question: experimentalHostUserNamespaceDefaulting: utilfeature.DefaultFeatureGate.Enabled(features.ExperimentalHostUserNamespaceDefaultingGate), keepTerminatedPodVolumes:                keepTerminatedPodVolumes, nodeStatusMaxImages:                     nodeStatusMaxImages, <ins> enablePluginsWatcher:                    utilfeature.DefaultFeatureGate.Enabled(features.KubeletPluginsWatcher), </ins> } if klet.cloud != nil {