Question: ginkgo.By("Sending the expected data to the local port") fmt.Fprint(conn, "abc") <del> ginkgo.By("Closing the write half of the client's connection") if err = conn.CloseWrite(); err != nil { framework.Failf("Couldn't close the write half of the client's connection: %v", err) } </del> ginkgo.By("Reading data from the local port") fromServer, err := ioutil.ReadAll(conn) if err != nil {

Which jobs are flaking: pull-kubernetes-e2e-gce Which test(s) are flaking: Testgrid link: /sig cli
This test seems to stop flake. Can you check if we can close this issue?
still looks flaky to me
Can you take a look?
/milestone v1.19
have you had a chance to look into this?
Possibly related to
Let's see if removing makes it less flaky


Question: func (*RemoveImageResponse) Descriptor() ([]byte, []int) { return fileDescriptorApi, []int{76} } type NetworkConfig struct { <del> // CIDR to use for pod IP addresses. </del> <ins> // CIDR to use for pod IP addresses. If the CIDR is empty, runtimes // should omit it. </ins> PodCidr string `protobuf:"bytes,1,opt,name=pod_cidr,json=podCidr,proto3" json:"pod_cidr,omitempty"` }

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In my test setup I allocate POD CIDRs manually, bridge is configured before starts. Important settings: on example node: on master: Then I see confusing entries in logs (): Fortunately everything keeps working, thanks to this condition: , i.e. it is not propagated to CNI plugin. It appears that this very line tries to set the CIDR to whatever the master returns during node status update: What you expected to happen: / use the pod CIDR given at command line and never mess with it Actually I'm a bit confused if manual per-node pod CIDR assignment is supported at all, and if I'm doing it correctly. I'm aware it's unusual thing to do in production environment, yet for testing it seems perfectly legitimate. Environment: Kubernetes version (use ): v1.10.0 Cloud provider or hardware configuration: bare metal OS (e.g. from /etc/os-release): Ubuntu 17.10 Kernel (e.g. ): Install tools:
/sig network
Kubelet need to make a check of CIDR before
/assign


Question: _, err = m.cs.StorageV1beta1().VolumeAttachments().Get(attachmentName, metav1.GetOptions{}) if err != nil { if errors.IsNotFound(err) { <del> if test.driverAttachable { </del> <ins> if !test.disableAttach { </ins> framework.ExpectNoError(err, "Expected VolumeAttachment but none was found") } } else { framework.ExpectNoError(err, "Failed to find VolumeAttachment") } } <del> if !test.driverAttachable { </del> <ins> if test.disableAttach { </ins> Expect(err).To(HaveOccurred(), "Unexpected VolumeAttachment found") } })

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear


Question: Httpd // HttpdNew image HttpdNew <del> // Invalid image Invalid </del> // InvalidRegistryImage image InvalidRegistryImage // IpcUtils image

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:


Question: // These are valid values for resource quota spec const ( <del> // Match all pod objects where spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds >=0 </ins> ResourceQuotaScopeTerminating ResourceQuotaScope = "Terminating" <del> // Match all pod objects where !spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds is nil </ins> ResourceQuotaScopeNotTerminating ResourceQuotaScope = "NotTerminating" // Match all pod objects that have best effort quality of service ResourceQuotaScopeBestEffort ResourceQuotaScope = "BestEffort"

The following comments are incomplete. For example, comments for "ResourceQuotaScopeTerminating" should be: Ref: /good-first-issue
/sig scheduling
/assign
Per ResourceQuota is within scope of api-machinery. /sig api-machinery /remove-sig scheduling
/assign
/unassign rakeshreddybandi
/remove-good-first-issue
Hi!! I'd like to help #investigate this problem I'm a beginner, so I'll make my best. Can you please help me point me in the right direction? What's the output today vs. how does the output should look like?
Oh I get it, the comments on top of the lines are not completely accurate on what the message displays, right? I think I got it
Yeah - But I've already opened a PR for this! - See the linked PR So this is already done, just waiting on final merge.
Great Dean, thanks for that!
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten


Question: func isResourceError(err error) bool { if ee, isExitError := err.(utilexec.ExitError); isExitError { return ee.ExitStatus() == iptablesStatusResourceProblem <del> } else { return false </del> } <ins> return false </ins> }

Anyone itching to understand the code and try fixing things in Kubernetes, please help fixing the lint failures Step 1: Remove one or two packages (related packages) from the list in - (note: do not change generated files, the name of defaulting functions, or the name of conversion functions... packages failing linting due to issues in those files will need to be left alone) Step 2: Run and look at the logged errors Step 3: Fix the code to ensure that runs cleanly. Step 4: Run and to make sure we fix any problems with gofmt or bazel. Step 5: File a PR with the change Step 6: Go to step :) Please use the tracking spreadsheet For everyone who is going to contribute, please append the packages you picked at the end. For existing contributor, please make sure this list is update to date
/sig architecture /sig testing
Hey, I would like to resolve this issue. Could you assign it to me ?
there are a lot of packages so there will be many people working on this. Also we cannot assign issue to folks who are not in the github org for kubernetes. please feel free to pick up a few packages like i mentioned and file a PR. Make sure you link back to this issue, so folks can see which packages you filed PR for.
OK. I see. I will firstly pick up the package called to fix.
Hi dims. Should i submit my PR before i remove one or two packages (related packages) from the list in - Or I first remove the package from list, then I fix the issue and submit a PR?
in your PR, you will have both the fixes to packages and some lines removed from /.golint_failures
When I run , I found some errors as below: I found that there is a go file in But there is still a error.
Say your GOPATH looks like this Your kubernetes directory should be () cd to and then run from that directory.
Is it necessary to obey all rules in golint? Rules in golint are set in stone. Maybe using gometalinter to ignore some specific errors is better?
I revise some erros about golint in some packages. Please review it.
which errors would you like to ignore?

if you can open a new issue with the list of errors to ignore (and proposing gometalinter), we can get some opinions there from others in the community.
Let me take the kubectl cmd part...
Can someone please review and let me know if I am doing it right?
I ll work on all the packages related to
we get 800-ish pkgs left to fix. my concern is that if we fix them package by package, then such pulls will be flooding the repo. can't we possibly make it in larger pulls? the larger the better?
+1 to slightly larger pulls with related packages. if allow too large then the reviewers will not be able to do a thorough review. we should spread the load among multiple reviewers. (if we allow a really large pull, we will end up with top level reviewers who will face the burden and the PR(s) will just stagnate)
oh good point. we could put one pkg's change into one commit, and merge all changes under one area into one pull so that it wont spread the load. wdyt? for each pull, we can have hundred-ish lines of change. but it will still be 30~50 pulls i guess? good news is that we can take our time to deal with it, at least before 1.12
sounds great! please feel free to help make it happen :) (by suggesting groups of packages that kinda go together)
I'm looking at fixing pkg/proxy, and I think I see what was talking about ignoring some rules. proxy.ProxyProvider is being suggested because golint is saying that it stutters. In that example, I think it's okay renaming it to proxy.Provider, but I could see an example where you would want to keep the stutter if the package that it's declared in uses it heavily.
sure thing, feel free to propose a PR for switching to gometalinter independently of other patches. We can work through that there.
I sent the pull request to fix pkg/volume/aws_ebs
I've fixed a few of these, but get the following error when I try to run : Are there any instructions on what I need to setup in order to resolve this?

you can find this file in
I have raised a PR to fix golint errors in pkg/api
I have fixed some pkgs under /pkg/kubelet pkg/kubelet/images pkg/kubelet/kuberuntime pkg/kubelet/leaky pkg/kubelet/pleg
I submitted a pull request for golint errors in pkg/security/ edit: I can work on picking up pkg/controller/bootstrap through pkg/controller/namespace/... (114-129)
fix golint errors in package cmd/kubeadm/app, since the codes under cmd/kubeadm/app/apis/kubeadm/v1alpha2 and cmd/kubeadm/app/apis/kubeadm/v1alpha3 are auto-generated, i keep them untouched.
I am working on some packages under pkg/kubelet, anyone interested in this plz leave messages for me :)
fix golint for pkg/util/dbus pkg/util/labels pkg/util/node pkg/util/strings pkg/util/workqueue/prometheus
PR fixes golint errors in pkg/routes,pkg/securitycontext, pkg/serviceaccount
PR fixes golint in pkg/probe
should we have a checklist as part of the issue summary saying what is in progress and what is done? Since this issue is getting long, this will make new contributors to pick up issues easier.
Great idea!, want to throw a google doc with a check-list so it's easy for participants to organize themselves? (please!) If it is the issue summary then one of us with privileges will be a bottle neck.
Created a with all the package that have on going PRs. Maybe you can add this to the summary. For everyone who is going to contribute, please append the packages you picked at the end. For existing contributor, please make sure this list is update to date
Thanks updated the spread sheet
Raised PR to fix golint issues in: pkg/controller/clusterroleaggregation pkg/controller/cronjob pkg/controller/daemon pkg/controller/deployment pkg/controller/deployment/util pkg/controller/disruption pkg/controller/endpoint
This issue is close in accident by . could you reopen it?
/reopen
Reopening 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
I found a problem trying to fix golint messages for .

Golint complaints on 's function because of the snake case. When I try to fix it, fails because it is being used in a code generated file. If I clean generated files, tests pass, but the generated file is not invoking it anymore. I failed to find the generator definition using this so I could change the hook to just . Also I'm not sure if this is wanted. I also found other packages in also probably affected by this. I read somewhere about replacing golint with gometalinter, which would allow to define directives in code to omit certain rules. I would consider to have a second exclusion file for golint with these cases, to be updated if move to gometalinter is finally done. This would make this issue completion more feasible. Meanwhile, I'll move onto fixing golint messages for other packages, until this discussion gets cleared.
I also found a problem fixing . A test fails because the directory is marked as readonly (see tests @ Shall we also ignore this directory for this issue?
Is this issue still relevant because hack/verify- is giving me no errors.
the failures are still present in there are details in the first message on how to claim + solve issues :)
Sorry I misunderstood the issue
I'm working on this package:
pkg/apis/admission/v1beta1 pkg/apis/authentication/v1beta1 pkg/apis/authorization/v1beta1 pkg/apis/coordination/v1 pkg/apis/coordination/v1beta1 pkg/apis/imagepolicy/v1alpha1 pkg/apis/scheduling/v1alpha1 pkg/apis/scheduling/v1beta1 pkg/apis/settings/v1alpha1 pkg/apis/storage/v1alpha1
pkg/cloudprovider/providers/vsphere/vclib pkg/kubelet/apis/deviceplugin/v1alpha pkg/kubelet/apis/pluginregistration/v1alpha1 pkg/kubelet/apis/pluginregistration/v1beta1
:
I'm looking at the pkg/registry/*, all those which are left. I expect to give an update on what all is fixed in the next 24-48 hours.
hi there is a google sheet that is a bit outdated, maybe you can update that?
hi I seem to only have view access for the sheet. Can't edit.
I fixed the permission.

Please try it again
pkg/apis/authentication pkg/apis/coordination pkg/apis/events pkg/apis/imagepolicy pkg/apis/settings
hi I think this issue was closed prematurely by (using fixes #issue in commit)
I'll put in a PR shortly for the package
Looking at next
hi thanks! there is a spreadsheet here that tracks the progress on fixing these issues, consider adding the packages you're work on there so we can keep everything organized :+1:
Starting on now
I did indeed see the Google Sheet link (thank you and to take it a little further
test/e2e
test/e2e_node/builder
pkg/registry/admissionregistration/mutatingwebhookconfiguration/storage pkg/registry/admissionregistration/rest pkg/registry/admissionregistration/validatingwebhookconfiguration/storage pkg/registry/apps/daemonset/storage
Hi. I opened a PR - Please review.
Working on Will open a PR soon.
Starting on and should have a PR soon
I keep getting this golint verify error on and was wondering if others saw it: But when I that package to the golint failures in my PR, my reviewer said it isn't necessary? What does that mean? What did I miss? Should I use a different kind of verify? cf:
looks like the disconnect is because that problem does not show up in the version of we use in the CI. please see
Still confused: is that not the golint version I ran? it installs from vendor and uses that I think?
i installed from and i still don't see the problem, can you please check what version of golint you have?
I'm confused why I wouldn't be using the vendored version? how would that get out of sync?
/me looking
Note: I am reserving for a KubeCon Contributor Workshop demonstration. It is noted in the spreadsheet.
I think may not be ideal cause there's a lot of auto generated files there. What do you think about reserving instead for the KubeCON Contributor Workshop?
pkg/apis/scheduling pkg/apis/storage/util pkg/apis/storage/v1beta1/util pkg/apis/storage/v1/util
/priority backlog
Hi I am a new contributor here, I'd like to contribute and make changes to the following file/s. I have marked it as WIP in the Google Sheet. Can someone let me know if I have to do anything else before I start working on this PR?

Umm so there's an issue where Golint tells that underscore shouldn't be allowed. Here's a log of the go-lint warnings:
Thanks The following should not be modified, as they are designed like this for code generation.
I'd like to pick a package and do my first PR, is there a list of packages to be done? Or should I correlate with this issue thread? Thanks in advance!
please see step 1 () please scan other PRs linked to this issue as well just in case.
Will do. Thank you. On Thu, Oct 3, 2019, 7:25 AM Davanum Srinivas <:
Hi there, I'm looking for a good first issue. I'll start taking a look at if that's ok? There doesn't seem to be anyone currently tracked as looking at it in the attached spreadsheet.
I've found a few others I'm actively looking at, you won't get any argument from me. On Sat, Oct 12, 2019, 10:38 AM Pamela Kelly <:
I am working on the iptables pkg. Updated in the google docs
/reopen
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
/reopen
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
I have problem running in step 2 $ hack/verify- what should I do?
PTAL for my pr to this issue, thx
you can move kubernetes directory to and re-run this script.
I'd like to take Can we fix linter issues for generated files? Or we should skip packages with zz_generated?
There're 2 lint errors that affects 292/507 packages, meaning it's not possible to cleanup the entire file without solving it: default pattern of Kubectl is the usage of [cmd]Options for initial options structs and it raises: /apis/{custommetrics,externalmetrics} for example raises the underscore error, but It's probably not worth to break backward compatibility renaming these folder for lint error fix: Any advice on these?

/reopen hm, cannot reopen this issue, it was closed by mistake
You can't reopen an issue/PR unless you authored it or you are a collaborator. <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
/reopen
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
I am sure this is all not fixed. Am I missing something? ./hack/verify- installing golint from vendor Congratulations! All Go source files have been linted.
you need to remove package from first.
/remove-sig testing SIG testing doesn't own code failing lints, we own the linter. :upsidedownface:
Hello, is this still a relevent issue ? I would like to work upon
I have fixed
Hi Folks, Some of the golint fixes, require us to change the exposed function's name, in simple words, "change API". I was not sure, if that is welcomed and what is the process.
Heres what Im getting after going over the following steps as mentioned by Say your GOPATH looks like this GOPATH=/Users/dims/go Your kubernetes directory should be ($) cd to and then run hack/verify- from that directory. I get the following output - installing golint Congratulations! All Go source files have been linted. Im not really sure what I am doing wrong. Any help is appreciated!
I think I understand. I misunderstood the steps around .golint_failures. The first step is to remove the pkg that we are targeting from this file and then run the My mistake was to assume that the packages in the file need to be removed after we are done cleaning the golint errors.
Can someone please review and let me know if I've done this right?
After a couple years of seeing changes spawned from this issue, I don't think this is a good use of contributors' or reviewers' time.

golint is very opinionated about: exported type and function names, leading to PRs attempting to change exported things people use downstream missing documentation on interface implementation functions, which leads to not-very-useful copy/paste of interface godoc the govet and staticcheck verify jobs are much more useful since they catch correctness issues, but I would recommend closing this issue and dropping the golint checks from CI golint doc itself discourages from using its output in an automated enforced way: from
i guess one can say gofmt is opinionated too, but something good about Golang is that it comes with an opinion and a set of standard tools. for API documentation at least we found inconsistencies on how most exported API items are documented: golint can help with that, but if there are no "pragmas" to avoid breaking changes and given we have codegen generating non-compliant names enabling golint on API packages is sort of blocked in Kubernetes. for non-API, non-library, non-public code, i think being inconsistent is mostly OK. no preference on my side. shrug
true, but code formatting has the benefits of mostly eliminating meaningless diffs in PRs due to code movement/whitespace/etc if there are specific packages (like API packages) we lack documentation on, adding checks specifically for that could make sense exactly, I don't think golint is the right tool for making sure we have API docs
golint itself doesn't have these and the go project is against this sort of comment AIUI, however golangci-lint does have them. I think there are plenty of other static analysis lints we should use instead, beyond just staticcheck and vet there is e.g.
btw, if we remove golint can we see e.g. all-caps constants or functions with underscores dodging review? perhaps we should add golangci-lint soon after:
Completely agree there are better places to spend review bandwidth. I was curious to see what the effort looked like. There have been 890 commits that touched over the past 3+ years !
/remove-help /remove-good-first-issue
Overall agree on the bandwidth. Also note that it was a good first issue with very low bar to get them in the repo. May be we need to find a similar low bar, but high value good first issue.

UT's come to mind, are there other things we curate for new contributors ?
Do we have an alternative way of enforcing that new exported code (not necessarily API fields) has at least some minimum documentation? As a reviewer, I ask contributors to add meaningful comments. But reality is that I sometimes stumble into old code that doesn't have documentation because we didn't have golint at some point. I agree that fix-golint PRs just add burden to reviewers. But, before removing the lint check, can we wait and see if it's enough to discourage people from sending more PRs like this? Additionally, we can encourage reviewers to just close PRs that only fix golint issues.
+1 for adding burden to reviewers. However, as a new contributor, I think this a very good opportunity for new contributors to study the code base and submit their first PR. In my opinion, I think this issue would be able to attract more new contributors, get familiar with the code base, and get familiar with the git workflow.
thanks everyone for getting us this far. We essentially gave up on the existing structure/system for golint: At some point we can look at adding golangci-lint, there's a WIP in progress in /close
Closing this issue. <detailsIn response to : thanks everyone for getting us this far. We essentially gave up on the existing structure/system for golint: 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: err := wait.Poll(framework.Poll, timeout, func() (bool, error) { endpoints, err := c.Endpoints(ns).Get(name) if err != nil { <del> if apierrs.IsNotFound(err) { </del> <ins> // log the real error framework.Logf("Get endpoints failed (interval %v): %v", framework.Poll, err) // if the error is API not found or could not find default credentials or TLS handshake timeout, try again if apierrs.IsNotFound(err) || apierrs.IsUnauthorized(err) || apierrs.IsServerTimeout(err) { </ins> err = nil } <del> framework.Logf("Get endpoints failed (interval %v): %v", framework.Poll, err) </del> return false, err }

https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention...


Question: }, HostConfig: &dockercontainer.HostConfig{ Binds: generateMountBindings(config.GetMounts()), <ins> RestartPolicy: dockercontainer.RestartPolicy{ Name: "no", }, </ins> }, }

As part of kubernetes/enhancements we encountered a potential bug. Environment: Kubernetes: 1.10 and 1.11 Docker version: from 17.03.1 checked on multiple cloudproviders. When a node restarts, and the kubelet cannot reach the apiserver, dockerd restarts all the containers in the node. the following logs are emitted: dockerd logs shows the following: when inspecting containers created by the kubelet we see that we create containers with the following restart policy: This is a blocker for kubernetes/enhancements as when the node restart the controller-manager cannot assume that it is safe to detach volumes as they might be mounted by the pods. /priority critical-urgent /kind bug /sig node
according to the docker doc, that looks correct: is this a docker bug?
does docker treat a system restart differently? I don't see a restart policy value other than / that would let us tell docker we didn't want containers auto-restarted on reboot
- forcing this to no mitigates the issue.
I couldn't reproduce this on my cluster (kubernets 1.13, GCE, COS image with docker 17.03.2-ce). I tried both methods -- 1) w/ k8s, stop apiserver, and restart the node, and 2) create a docker container with empty restart policy, reboot the node. Since this can be a docker bug, could you get an os image version + docker version, and commands to reproduce this?
- apologies, I double-checked both hosts were on 17.03.1-ce, I tried to reproduce with 17.3.2 but wasn't able to do so. From the nothing seems have fixed the issue. Can you confirm that you are able to reproduce the issue on 17.3.1 ? Also forcing the restartPolicy to mitigates the issue for this version. It seems like isn't treated consistently. - do you have any concern to change dockershim to set explicitly a restart policy to ?
It appears we are depending on the implicit default of "no" currently () If that behaves inconsistently on different docker versions, I think making it explicit is reasonable.
sgtm


Question: sourcesReady:          sourcesReady, clusterDomain:         clusterDomain, clusterDNS:            clusterDNS, <del> } </del> <ins> }, nil </ins> } type httpGetter interface {

Things like SyncFrequency should have a lower-bound of acceptable, and that really should be 0ns.
The main point of this is now fixed, though we could be better about input checking all over


Question: assert.Equal(t, test.expected, real, test.desc) } } <ins> func TestIsBackendPoolOnSameLB(t *testing.T) { tests := []struct { backendPoolID        string existingBackendPools []string expected             bool expectedLBName       string expectError          bool }{ { backendPoolID: "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1/backendAddressPools/pool1", existingBackendPools: []string{ "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1/backendAddressPools/pool2", }, expected:       true, expectedLBName: "", }, { backendPoolID: "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1-internal/backendAddressPools/pool1", existingBackendPools: []string{ "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1/backendAddressPools/pool2", }, expected:       true, expectedLBName: "", }, { backendPoolID: "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1/backendAddressPools/pool1", existingBackendPools: []string{ "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1-internal/backendAddressPools/pool2", }, expected:       true, expectedLBName: "", }, { backendPoolID: "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1/backendAddressPools/pool1", existingBackendPools: []string{ "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb2/backendAddressPools/pool2", }, expected:       false, expectedLBName: "lb2", }, { backendPoolID: "wrong-backendpool-id", existingBackendPools: []string{ "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1/backendAddressPools/pool2", }, expectError: true, }, { backendPoolID: "/subscriptions/sub/resourceGroups/rg/providers/Microsoft.Network/loadBalancers/lb1/backendAddressPools/pool1", existingBackendPools: []string{ "wrong-existing-backendpool-id", }, expectError: true, }, { backendPoolID: "wrong-backendpool-id", existingBackendPools: []string{ "wrong-existing-backendpool-id", }, expectError: true, }, } for _, test := range tests { isSameLB, lbName, err := isBackendPoolOnSameLB(test.backendPoolID, test.existingBackendPools) if test.expectError { assert.Error(t, err) continue } assert.Equal(t, test.expected, isSameLB) assert.Equal(t, test.expectedLBName, lbName) } } </ins>

<!-- 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: SLB backend pools are empty if outbound rules are defined in a separate backend pool. This is because, although we the check for not adding the backend pools from different LBs, the lbName is not checked: The new backend pool's lbName should be also checked in above codes. What you expected to happen: SLB backend pools should be updated correctly when outbound rules are defined in a separate backend pool. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /sig azure /kind bug /assign


Question: func DeepCopyJSONValue(x interface{}) interface{} { switch x := x.(type) { case map[string]interface{}: <ins> if x == nil { // Typed nil - an interface{} that contains a type map[string]interface{} with a value of nil return x } </ins> clone := make(map[string]interface{}, len(x)) for k, v := range x { clone[k] = DeepCopyJSONValue(v) } return clone case []interface{}: <ins> if x == nil { // Typed nil - an interface{} that contains a type []interface{} with a value of nil return x } </ins> clone := make([]interface{}, len(x)) for i, v := range x { clone[i] = DeepCopyJSONValue(v)

What happened: In I introduced an optimization - do a deep copy instead of to and from JSON roundtrip to convert anything that implements . I then discovered that the method that is used there in both and may mutate the original object. This is problematic because previously (before ) there was no mutation and because this is unexpected and may lead to data races - it is bad behaviour to mutate original object when you just want a copy of it. This issue was fixed by . However the underlying issue is not fixed here - is brittle and dangerous. Method name does not imply that it mutates data when you call it. And godoc does not mention that either: Something needs to be done about it IMO. This method is misused in these places (mutation side effect is not intended): Also implementation in does not implement the behaviour required by godoc in . What you expected to happen: There should be a method that returns the current unstructured contents without mutation and perhaps not providing the write-through effect. /kind bug /sig api-machinery
/cc
Is this still required and could I work on it? I'm looking for something to work on as a new contributor :)
Yes and yes! :)
Perfect, I'll get started on it!
I've got out. I'd appreciate a review :)
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: }, }, { <ins> name:                "PVC does not exist", pod:                 makePod("pod-a", []string{"pvc-a"}), node:                &v1.Node{}, pvcs:                []*v1.PersistentVolumeClaim{}, wantPreFilterStatus: framework.NewStatus(framework.UnschedulableAndUnresolvable, `persistentvolumeclaim "pvc-a" not found`), }, { name: "Part of PVCs do not exist", pod:  makePod("pod-a", []string{"pvc-a", "pvc-b"}), node: &v1.Node{}, pvcs: []*v1.PersistentVolumeClaim{ makePVC("pvc-a", "pv-a", waitSC.Name), }, wantPreFilterStatus: framework.NewStatus(framework.UnschedulableAndUnresolvable, `persistentvolumeclaim "pvc-b" not found`), }, { </ins> name: "immediate claims not bound", pod:  makePod("pod-a", []string{"pvc-a"}), node: &v1.Node{},

What would you like to be : Scheduler VolumeBinding plugin reports error when a PVC doesn't exist for example: We need to take a second look at the VolumeBinding plugin and make sure that errors are returned only when there is a system error, not a user error. Why is this needed: To fix the scheduler's error reporting metrics. /sig scheduling /sig storage /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
/assign I'll take a look.
If the PVC object does not exist, the plugin will return status. I guess you mean the plugin will return an error when a referenced PV does not exist? I've created a PR for this:
Thanks! The errors I am seeing are on 1.18 clusters, can we look at 1.18 and try to patch? This is still throwing the scheduler's error metrics off.
sure
I've submitted a patch for the 1.18 release branch:
I guess on the master branch should be reviewed and merged too? cc
hello! the fix you made only apply for 1.18? how about 1.19 and 1.17? thanks!
after the fix on the master branch () is merged, I'll cherry-pick it into the 1.19 branch (the code are almost the same). I'm not sure if it's necessary to fix the 1.17 branch. It's 3 versions behind 1.20.
hi, This is because of this patch: Do you think this fix needs to be cherry-picked into 1.19 and 1.18 branch too?
can you send a patch for 1.19?
ah, here it is
to sum up: master: 1.19: 1.18: and I think this change should be backported to 1.19/1.18 too: I'll send PRs soon.

summary of the issue that an error will be reported instead of UnschedulableAndUnresolvable when PVC not found: master: already implemented, see 1.19: 1.18: can't backport as it does not implement the PreFilter extension point


Question: } func (q *graceTerminateRSList) flushList(handler func(rsToDelete *listItem) (bool, error)) bool { <ins> q.lock.Lock() defer q.lock.Unlock() </ins> success := true for name, rs := range q.list { deleted, err := handler(rs)

! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)


Question: t.Errorf("missing watch event") } } <ins> func TestSelfLink(t *testing.T) { stopCh, apiExtensionClient, clientPool, err := testserver.StartDefaultServer() if err != nil { t.Fatal(err) } defer close(stopCh) noxuDefinition := testserver.NewNoxuCustomResourceDefinition() noxuVersionClient, err := testserver.CreateNewCustomResourceDefinition(noxuDefinition, apiExtensionClient, clientPool) if err != nil { t.Fatal(err) } ns := "not-the-default" noxuNamespacedResourceClient := noxuVersionClient.Resource(&metav1.APIResource{ Name:       noxuDefinition.Spec.Names.Plural, Namespaced: true, }, ns) noxuInstanceToCreate := testserver.NewNoxuInstance(ns, "foo") createdNoxuInstance, err := noxuNamespacedResourceClient.Create(noxuInstanceToCreate) if err != nil { t.Fatal(err) } if e, a := "/apis/mygroup.example.com/v1alpha1/namespaces/not-the-default/noxus/foo", createdNoxuInstance.GetSelfLink(); e != a { t.Errorf("expected %v, got %v", e, a) } // TODO add test for cluster scoped self-link when its available } </ins>

as discussed via IRC my understanding is that customResource selfLink is broken. For example for resource created the selfLink is while as far as I understand it should be something like: disregard in case I'm wrong.


Question: for _, v := range s.XValidations { expressions.rules.Insert(v.Rule) if len(v.MessageExpression) > 0 { <del> expressions.messageExpressions.Insert(v.Rule) </del> <ins> expressions.messageExpressions.Insert(v.MessageExpression) </ins> } } return false

Noticed a copy & paste issue when reading through the CEL code. Basically here: This should be instead of: The impact of this issue should be that messageExpressions are always evaluated with the CEL environment of the compatibility version. But stored (i.e. pre-existing) messageExpressions should be evaluated with a CEL environment with the "max" version instead. For users of Kubernetes this means that messageExpressions deployed with one minor version of Kubernetes might not work anymore if they rollback e.g. by one minor version. messageExpressions should be treated the same way as rules in that regard. Deploy Kubernetes 1.30 Deploy CRD that uses messageExpression that is using Sets (which became available with Kubernetes 1.30 that is using compatibilty version 1.29) Rollback to Kubernetes 1.29 Update something in the CRD =CRD update will fail because messageExpression is evaluated with the wrong CEL environment (it should still work) No response <detailsAt least on Kubernetes main, but I would assume this isuse is there since CEL was implemented </details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc Will open a PR in a bit


Question: newService("s2", "666", true), }, expectedUpdateCalls: []fake_cloud.FakeUpdateBalancerCall{ <del> {Name: lbName("s0"), Region: region, Hosts: []string{"node0", "node1", "node73"}}, {Name: lbName("s1"), Region: region, Hosts: []string{"node0", "node1", "node73"}}, {Name: lbName("s2"), Region: region, Hosts: []string{"node0", "node1", "node73"}}, </del> <ins> {Name: "a444", Region: region, Hosts: []string{"node0", "node1", "node73"}}, {Name: "a555", Region: region, Hosts: []string{"node0", "node1", "node73"}}, {Name: "a666", Region: region, Hosts: []string{"node0", "node1", "node73"}}, </ins> }, }, {

Since this PR got merged, the ELB e2e test, which was consistently succeeding, is now consistently failing: Revert now that is in, and fix the tests that were relying on it. (details) Commit by arob Revert now that is in, and fix the tests that were relying on it. The file was modified The file was modified The file was modified I'm going to roll it back to confirm.


Question: gvr("flowcontrol.apiserver.k8s.io", "v1beta1", "flowschemas"): { Stub:             `{"metadata": {"name": "va2"}, "spec": {"priorityLevelConfiguration": {"name": "name1"}}}`, ExpectedEtcdPath: "/registry/flowschemas/va2", <del> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta2", "FlowSchema"), </del> <ins> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta3", "FlowSchema"), </ins> }, // --

adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/cc
/triage accepted
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]:


Question: } nodesTests := []jsonpathTest{ <del> {"range item", `{range .items[*]}{.metadata.name}, {end}{.kind}`, nodesData, "127.0.0.1, 127.0.0.2, List"}, {"range item with quote", `{range .items[*]}{.metadata.name}{"t"}{end}`, nodesData, "127.0.0.1t127.0.0.2t"}, </del> <ins> {"range item", `{range .items[*]}{.metadata.name}, {end}{.kind}`, nodesData, "127.0.0.1, 127.0.0.2, List", false}, {"range item with quote", `{range .items[*]}{.metadata.name}{"t"}{end}`, nodesData, "127.0.0.1t127.0.0.2t", false}, </ins> {"range addresss", `{.items[*].status.addresses[*].address}`, nodesData, <del> "127.0.0.1 127.0.0.2 127.0.0.3"}, </del> <ins> "127.0.0.1 127.0.0.2 127.0.0.3", false}, </ins> {"double range", `{range .items[*]}{range .status.addresses[*]}{.address}, {end}{end}`, nodesData, <del> "127.0.0.1, 127.0.0.2, 127.0.0.3, "}, {"item name", `{.items[*].metadata.name}`, nodesData, "127.0.0.1 127.0.0.2"}, </del> <ins> "127.0.0.1, 127.0.0.2, 127.0.0.3, ", false}, {"item name", `{.items[*].metadata.name}`, nodesData, "127.0.0.1 127.0.0.2", false}, </ins> {"union nodes capacity", `{.items[*]['metadata.name', 'status.capacity']}`, nodesData, <del> "127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]"}, </del> <ins> "127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]", false}, </ins> {"range nodes capacity", `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}`, nodesData, <del> "[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] "}, {"user password", `{.users[?(@.name=="e2e")].user.password}`, &nodesData, "secret"}, {"hostname", `{.items[0].metadata.labels.kubernetes.io/hostname}`, &nodesData, "127.0.0.1"}, {"hostname filter", `{.items[?(@.metadata.labels.kubernetes.io/hostname=="127.0.0.1")].kind}`, &nodesData, "None"}, {"bool item", `{.items[?(@..ready==true)].metadata.name}`, &nodesData, "127.0.0.1"}, </del> <ins> "[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] ", false}, {"user password", `{.users[?(@.name=="e2e")].user.password}`, &nodesData, "secret", false}, {"hostname", `{.items[0].metadata.labels.kubernetes.io/hostname}`, &nodesData, "127.0.0.1", false}, {"hostname filter", `{.items[?(@.metadata.labels.kubernetes.io/hostname=="127.0.0.1")].kind}`, &nodesData, "None", false}, {"bool item", `{.items[?(@..ready==true)].metadata.name}`, &nodesData, "127.0.0.1", false}, </ins> } testJSONPath(nodesTests, false, t) randomPrintOrderTests := []jsonpathTest{ <del> {"recursive name", "{..name}", nodesData, `127.0.0.1 127.0.0.2 myself e2e`}, </del> <ins> {"recursive name", "{..name}", nodesData, `127.0.0.1 127.0.0.2 myself e2e`, false}, </ins> } testJSONPathSortOutput(randomPrintOrderTests, t) } <ins> func TestFilterPartialMatchesSometimesMissingAnnotations(t *testing.T) { // for https://issues.k8s.io/45546 var input = []byte(`{ "kind": "List", "items": [ { "kind": "Pod", "metadata": { "name": "pod1", "annotations": { "color": "blue" } } }, { "kind": "Pod", "metadata": { "name": "pod2" } }, { "kind": "Pod", "metadata": { "name": "pod3", "annotations": { "color": "green" } } }, { "kind": "Pod", "metadata": { "name": "pod4", "annotations": { "color": "blue" } } } ] }`) var data interface{} err := json.Unmarshal(input, &data) if err != nil { t.Fatal(err) } testJSONPath( []jsonpathTest{ { "filter, should only match a subset, some items don't have annotations, tolerate missing items", `{.items[?(@.metadata.annotations.color=="blue")].metadata.name}`, data, "pod1 pod4", false, // expect no error }, }, true, // allow missing keys t, ) testJSONPath( []jsonpathTest{ { "filter, should only match a subset, some items don't have annotations, error on missing items", `{.items[?(@.metadata.annotations.color=="blue")].metadata.name}`, data, "", true, // expect an error }, }, false, // don't allow missing keys t, ) } </ins>

On , will fail to evaluate a filter when the member does not exist: For instance, if I were to execute Where not all in that namespace had the annotation, this would fail with the error message: This is confusing as it leads me to think more than one item was selected, so while it is not technically incorrect the error message is misleading. I would furthermore expect to more gracefully handle this case -- a missing here means that the filter should fail, not error.
What do you mean by ? How is it different from ?
As in, don't add that item to the list of items on which the following access is made. When I do: And there is no annotation on , I just get nothing back -- no error, just nothing. Similarly, i would have expected the filtered expression to give me the for all of the pods that have an annotation with value . That, anyway is what I understand the JSONPath syntax to mean. When you write You are saying:
cc since you authored and I'm not sure how we want to fix this.
Taking a look now
it looks like you need to do this (note that the annotations portion is wrapped by ): I wrote a unit test and it worked as expected. PTAL!
I'm pretty sure that was a typo on my end but let me check -- do you have a reproducer script?
I see an entirely different error today... weird:
Ok so you have 1 object with annotations, and 1 without. Let me look into that case.
Let me add another annotation to
No difference if both have annotations:
Ok, I'll have to test using kubectl
I'm the Origin bundled but I don't think there are any patches on JSONPath there:
I'm able to reproduce in the unit test when 1 object has annotations and the other does not, if allowMissingKeys is true for the jsonpath parser.
I see. Let me know if I can be of more help.
I think I have a fix. PR coming soon.
Possible


Question: return notMnt, mountPointsErr } for _, mp := range mountPoints { <del> if mounter.IsMountPointMatch(mp, file) { </del> <ins> if mounter.IsMountPointMatch(mp, resolvedFile) { </ins> notMnt = false break }

This is related to and , but these issues contain several different bugs, so I am creating a new one. Steps to reproduce: must be a symlink somewhere else. If you don't have a symlink, then it's a different bug. a pod with ConfigMap volume with SubPath: (the pod should run just fine) -The pod is Terminating forever From the logs: You can see there is no "Unmounting /var/lib/kubelet/pods/-ba83-11e8-983c-/volume-subpaths/vol/busybox/0", so kubelet did not even try to unmount it. Environment: Kubernetes version 1.9.x (and today's master). /kind bug /sig storage another subpath bug :-)
Posted , kubelet gets confused by /var/lib/kubelet being a symlinks and it looks for /var/lib/kubelet/pods/... in /proc/mounts instead of target of the symlink.


Question: package fieldmanager import ( <ins> "fmt" v1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "reflect" "testing" "time"

I created an object with , and later I updated the same object with another . After that I looked at the object's managedFields, and saw nothing about the update. Here is what I got after the second apply: I expected managedFields to get updated by the second . No response <details</details<detailsnone </details<details</details<detailskubeadm </details<detailsdocker </details<details</details
/cc
I also saw the timestamp not updated when I updated using client-go and typed client stubs, Apply method, patch type .
/assign /triage accepted
/cc
The is not updated because you are not changing the structure of the object (adding or removing fields). According to , the time is updated if and only if the fieldSet is changed. It does not take into account the value of fields. One option would be to not compare the fieldSets but directly compare the liveObject & newObject for differences and update the field accordingly. Is it the desired behavior to update the time of when only the value is updated?
Yes! Look at the first paragraph of .
is that documentation correct? Is this what we intended?
I don't see any mention to the timestamp in that first paragraph. We've clarified recently the exact semantic of the timestamp, as defined here: I think you've identified the wrong code if you want to go ahead and fix it, go ahead, I'll happily review!


Question: } } } <ins> func TestSNICert(t *testing.T) { stopCh := make(chan struct{}) defer close(stopCh) var servingCertPath string _, kubeconfig := framework.StartTestServer(t, stopCh, framework.TestServerSetup{ ModifyServerRunOptions: func(opts *options.ServerRunOptions) { opts.GenericServerRunOptions.MaxRequestBodyBytes = 1024 * 1024 servingCertPath = opts.SecureServing.ServerCert.CertDirectory if err := ioutil.WriteFile(path.Join(servingCertPath, "foo.key"), anotherServerKey, 0644); err != nil { t.Fatal(err) } if err := ioutil.WriteFile(path.Join(servingCertPath, "foo.crt"), anotherServerCert, 0644); err != nil { t.Fatal(err) } dynamiccertificates.FileRefreshDuration = 1 * time.Second opts.SecureServing.SNICertKeys = []flag.NamedCertKey{{ Names:    []string{"foo"}, CertFile: path.Join(servingCertPath, "foo.crt"), KeyFile:  path.Join(servingCertPath, "foo.key"), }} }, }) apiserverURL, err := url.Parse(kubeconfig.Host) if err != nil { t.Fatal(err) } // When we run this the second time, we know which one we are expecting. acceptableCerts := [][]byte{} tlsConfig := &tls.Config{ InsecureSkipVerify: true, VerifyPeerCertificate: func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error { acceptableCerts = make([][]byte, 0, len(rawCerts)) for _, r := range rawCerts { acceptableCerts = append(acceptableCerts, r) } return nil }, ServerName: "foo", } conn, err := tls.Dial("tcp", apiserverURL.Host, tlsConfig) if err != nil { t.Fatal(err) } conn.Close() cert, err := tls.LoadX509KeyPair(path.Join(servingCertPath, "foo.crt"), path.Join(servingCertPath, "foo.key")) if err != nil { t.Fatal(err) } expectedCerts := cert.Certificate if len(expectedCerts) != len(acceptableCerts) { var certs []string for _, a := range acceptableCerts { certs = append(certs, base64.StdEncoding.EncodeToString(a)) } t.Fatalf("Unexpected number of certs: %v", strings.Join(certs, ":")) } for i := range expectedCerts { if !bytes.Equal(acceptableCerts[i], expectedCerts[i]) { t.Errorf("expected %q, got %q", base64.StdEncoding.EncodeToString(expectedCerts[i]), base64.StdEncoding.EncodeToString(acceptableCerts[i])) } } if err := ioutil.WriteFile(path.Join(servingCertPath, "foo.key"), serverKey, 0644); err != nil { t.Fatal(err) } if err := ioutil.WriteFile(path.Join(servingCertPath, "foo.crt"), serverCert, 0644); err != nil { t.Fatal(err) } time.Sleep(4 * time.Second) conn2, err := tls.Dial("tcp", apiserverURL.Host, tlsConfig) if err != nil { t.Fatal(err) } conn2.Close() cert, err = tls.X509KeyPair(serverCert, serverKey) if err != nil { t.Fatal(err) } expectedCerts = cert.Certificate if len(expectedCerts) != len(acceptableCerts) { var certs []string for _, a := range acceptableCerts { certs = append(certs, base64.StdEncoding.EncodeToString(a)) } t.Fatalf("Unexpected number of certs: %v", strings.Join(certs, ":")) } for i := range expectedCerts { if !bytes.Equal(acceptableCerts[i], expectedCerts[i]) { t.Errorf("expected %q, got %q", base64.StdEncoding.EncodeToString(expectedCerts[i]), base64.StdEncoding.EncodeToString(acceptableCerts[i])) } } } </ins>

When we want to rotate certificates for aggregated API servers, we have to restart (kill) pods in order for API server to pick the new certificates. It would be very useful to implement some sort of self-awareness for the aggregated API servers, so they can pick-up new certificates when they're updated, without user interaction. If we have certificate files in pods, that are provided by some volumeSource, that can be persistent storage or a Secret, when file gets changed on the volume, the kubelet updates file in the pod usually in matters of few seconds. However, aggregated API servers are not self-aware of such change and users have to manually restart the pods. This brings additional complexity, especially if you want to automate the process. The first problem is that you need to know what pods you need to restart. But the potentially biggest problem is that you need additional permissions to do so. That would include RBAC permissions for listing pods, listing deployments and for deleting pods. That can make a security issue in some setups. By making aggregated API servers sort of self-aware, this could be avoided. Create a health check somewhere in , that utilizes a file watcher to watch for certificates changes. When certificate is changed, fail a health check. Failing health check will restart the pod without user interaction. This could be the most easiest and simplest solution to the problem. Such feature should/could be optional and guarded by a flag, let's name it . Some delay could be required between restarting pods. We probably don't want to kill all pods in the same time. This is up to be discussed. I would like to work on this issue, so feel free to assign it to me. /kind feature /sig api-machinery /area apiserver /cc
this could also be done by a purpose-built container that watched the same input files. as you point out, you likely would not want to restart all apiservers at once, which makes it unclear whether you'd want to build in the restart logic to the individual servers
That coordination would certainly work and be a valuable tool for someone to build to help manage rolling generic processes if we never get a pod restart. However, being able to have a "usually won't all go down together" option built-in is easy to understand and will resolve the problem until then.

It isn't a stretch to say that if your process isn't fulfilling the current intent of the pod, it isn't healthy. This gives us a thing between dynamic config reloading and nothing. A container that can coordinate based on a service would be really cool, but I think that'd be a separate thing.
/cc
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
/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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: cd "${KUBE_ROOT}" <ins> ret=0 TYPECHECK_SERIAL="${TYPECHECK_SERIAL:-false}" SERVER_PLATFORMS=$(echo "${KUBE_SUPPORTED_SERVER_PLATFORMS[@]}" | tr ' ' ',') CLIENT_PLATFORMS=$(echo "${KUBE_SUPPORTED_CLIENT_PLATFORMS[@]}" | tr ' ' ',') NODE_PLATFORMS=$(echo "${KUBE_SUPPORTED_NODE_PLATFORMS[@]}" | tr ' ' ',') TEST_PLATFORMS=$(echo "${KUBE_SUPPORTED_TEST_PLATFORMS[@]}" | tr ' ' ',') </ins> # As of June, 2020 the typecheck tool is written in terms of go/packages, but # that library doesn't work well with multiple modules.  Until that is done, # force this tooling to run in a fake GOPATH. <del> ret=0 TYPECHECK_SERIAL="${TYPECHECK_SERIAL:-false}" </del> hack/run-in-gopath.sh  <del> go run test/typecheck/main.go "$@" "--serial=$TYPECHECK_SERIAL" || ret=$? </del> <ins> go run test/typecheck/main.go "$@" --serial="${TYPECHECK_SERIAL}" --platform "${SERVER_PLATFORMS}" "${KUBE_SERVER_TARGETS[@]}"  || ret=$? hack/run-in-gopath.sh  go run test/typecheck/main.go "$@" --serial="${TYPECHECK_SERIAL}" --platform "${CLIENT_PLATFORMS}" "${KUBE_CLIENT_TARGETS[@]}"  || ret=$? hack/run-in-gopath.sh  go run test/typecheck/main.go "$@" --serial="${TYPECHECK_SERIAL}" --platform "${NODE_PLATFORMS}" "${KUBE_NODE_TARGETS[@]}"  || ret=$? # $KUBE_TEST_TARGETS doesn't seem to work like the other TARGETS variables... hack/run-in-gopath.sh  go run test/typecheck/main.go "$@" --serial="${TYPECHECK_SERIAL}" --platform "${TEST_PLATFORMS}" test/e2e  || ret=$? </ins> if [[ $ret -ne 0 ]]; then echo "!!! Type Check has failed. This may cause cross platform build failures." >&2 echo "!!! Please see https://git.k8s.io/kubernetes/test/typecheck for more information." >&2

In I tried to reorganize the kube-proxy build a bit, and ran into the problem that verify-typecheck failed because was no longer buildable on darwin/amd64 and darwin/arm64. This was surprising because we don't build kube-proxy on OS X. It seems like verify-typecheck ought to be taking / from into account when deciding what to check. There's no reason to be checking the OS X type compatibility of binaries that we don't build on OS X.
/sig network
/remove-sig network /sig testing Agree, we need to plumb this through. We should also consider plumbing through static vs non-static and cgo enable/disable while we're at it. The goal is to be a low-fidelity cross-build to catch most code errors that would break the full without actually having to run the computationally expensive cross build, but there's some mismatch ...
/triage accepted


Question: # if the url belongs to GCS API we should use oauth2_token in the headers curl_headers="" if { [[ "${KUBERNETES_PROVIDER:-gce}" == "gce" ]] || [[ "${KUBERNETES_PROVIDER}" == "gke" ]] ; } && <del> [[ "$kubernetes_tar_url" =~ ^https://storage.googleapis.com.* ]] && valid-storage-scope ; then curl_headers="Authorization: Bearer $(get-credentials)" </del> <ins> [[ "$kubernetes_tar_url" =~ ^https://storage.googleapis.com.* ]] ; then curl_headers="Authorization: Bearer $(gcloud auth print-access-token)" </ins> fi curl ${curl_headers:+-H "${curl_headers}"} -fL --retry 3 --keepalive-time 2 "${kubernetes_tar_url}" -o "${file}" elif [[ $(which wget) ]]; then

Many jobs are failing because of Some of the job logs: /priority critical-urgent /cc /cc /milestone v1.18 /sig release
Also, all the jobs report in their log the following: Do we have to take any action to change that?
After some investigation, it seems that file contains instead of
Switching from to podutils should be done by the job owners - this is out of scope for releas team (strictly speaking). And the message is just a warning, should not affect the job itself.
is this related to the workload identity switch yesterday?
Maybe? get- does seem to pass auth headers, possibly this part isn't working correctly? These jobs explicitly mount a service- though so I wouldn't expect workload identity to change things but I could be wrong...
Yes, this will not work until we attach a kubernetes service account to the job that uses workload identity:
Ideally that command should become (and let it decide how to best authenticate) rather than assuming the script runs on a VM
/assign
sent
/reopen doesn't seem to solve the issue. The jobs are still failing because of this reason. Do we need any more actions after ????
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
I don't agree, the definitely helped in case of e2e scalability jobs, our presubmits and continuous jobs started passing again, e.g. https://k8s-
Looks green?
Only the 1.18 jobs are green. We need to cherry-pick the fix to the other branches as well. I will keep this issue open.
For some reason I thought kubetest always used the copy from HEAD.
in the case that it didn't we'll need this cherry picked to all active branches :|
I thought the same, but indeed the fixed only 1.18 and master jobs. Older release scalability jobs are still broken ! It's a bit confusing TBH. I thought that get- is always downloaded by kubetest from which IIUC points to the master branch.

Alternatively, get- could've been embedded in the kubekins image, but if that was the case then couldn't have fixed our 1.18/master tests without kubekins version update (which didn't happen). Another options is that kubetest downloads get- from proper release branches, but I couldn't find such logic in the kubetest code. would you mind explaining how it works?
There are a lot of jobs that are failing because of this. - master - 1.18 7 jobs in 1.17 branch 5 jobs in 1.16 branch 5 jobs in 1.15 branch Can you please take a look?
/sig testing
Ping, any updates?
filed a number of cherry picks for the script
Closing... The issue has been resolved. Thanks, /close
Closing this issue. <detailsIn response to : Closing... The issue has been resolved. Thanks, /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: import ( "context" "fmt" <del> "io" "os" </del> "path/filepath" "strings" "time"

What happened: We've been doing some release readiness and auditing all tagged ginkgo tests... Looks like The test seems to expect a GOPATH when running. Im seeing some failures in sonobuoy and suspect a possible relation there but havent dove into it. Either way, its clear this test might need some updating/fixing/cleanuping and parts can be rewritten/improved. What you expected to happen: No reliance on GOPATH for an e2e test ... I dont remember the whole history on this, but no tests that rely on static files currently look in gopath, from what i can tell ? instead we plumbed in a repo-root/ option a few years ago. There may be a state of the art in terms of how we do this.... but i thought it was at one point which was an option passed in. How to reproduce it (as minimally and precisely as possible): Try to run this in sonobuoy or any other environment where there's no GOPATH or non-standard source trees, pretty sure it might not work. Anything else we need to know?: I think the fix here is to just embed the YAML in golang like we do in other tests. along the way there's other cleanup we can do to improve this test. Environment: Kubernetes version (use ): master
/sig network
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
the YAML files are pretty small, so +1 to embed them in i don't think testing the YAML from the separate repository () directly is required here. ref /help /kind cleanup /priority backlog
/remove-help
/assign Also I should say, I talked to Jay on slack and he is ok with me taking a look at it, if thats ok.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
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
/remove-lifecycle stale
xref: go 1.16 has built in support for embedding go 1.17 looks to be removing GOPATH
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
/remove-lifecycle stale
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]:
/help wanted
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]:
/remove-lifecycle rotten still a problem. FYI re: GOPATH removal
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]:
/assign


Question: // did we find it? if newDevicePath != "" { <del> // the current sequence k8s uses for unformated disk (check-disk, mount, fail, mkfs.extX) hangs on // Azure Managed disk scsi interface. this is a hack and will be replaced once we identify and solve // the root case on Azure. formatIfNotFormatted(newDevicePath, *volumeSource.FSType, exec) </del> return true, 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?: /kind bug What happened: When use an existing azure disk(also called ) in pod, if that disk has partitions, the disk will be formatted in the pod mounting. What you expected to happen: How to reproduce it (as minimally and precisely as possible): create a disk with source from an os disk, e.g. that disk is already formatted before pod could access it Anything else we need to know?: Root cause: current diskLooksUnformatted func is using command to check whether disk is formatted or not while common k8s code() is using to detect disk format, could detect multiple partitions so if we use common k8s code(), following error will be returned for mulitple partition disks, which is expected: Environment: Kubernetes version (use ): v1.7 - v1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
cc
iirc we don't support partitions on Azure volumes. There was a specific hang long ago. in all cases i think should be safe to based check now via the underlaying api
thanks for the info, I am writing this PR, and also testing carefully. And this issue depends on , could you review it first? Thanks.


Question: } } } <del> } else if !inspectResult.State.FinishedAt.IsZero() { </del> <ins> } else if !inspectResult.State.FinishedAt.IsZero() || inspectResult.State.ExitCode != 0 { // When a container fails to start State.ExitCode is non-zero, FinishedAt and StartedAt are both zero </ins> reason := "" <del> message := "" </del> <ins> message := inspectResult.State.Error finishedAt := unversioned.NewTime(inspectResult.State.FinishedAt) startedAt := unversioned.NewTime(inspectResult.State.StartedAt) </ins> // Note: An application might handle OOMKilled gracefully. // In that case, the container is oom killed, but the exit // code could be 0. if inspectResult.State.OOMKilled { reason = "OOMKilled" <del> } else { </del> <ins> } else if inspectResult.State.ExitCode == 0 { reason = "Completed" } else if !inspectResult.State.FinishedAt.IsZero() { </ins> reason = "Error" <del> message = inspectResult.State.Error </del> <ins> } else { // finishedAt is zero and ExitCode is nonZero occurs when docker fails to start the container reason = ErrContainerCannotRun.Error() // Adjust time to the time docker attempted to run the container, otherwise startedAt and finishedAt will be set to epoch, which is misleading finishedAt = unversioned.NewTime(inspectResult.Created) startedAt = unversioned.NewTime(inspectResult.Created) </ins> } result.status.State.Terminated = &api.ContainerStateTerminated{ <del> ExitCode: inspectResult.State.ExitCode, Message:  message, Reason:   reason, StartedAt:   unversioned.NewTime(inspectResult.State.StartedAt), FinishedAt:  unversioned.NewTime(inspectResult.State.FinishedAt), </del> <ins> ExitCode:    inspectResult.State.ExitCode, Message:     message, Reason:      reason, StartedAt:   startedAt, FinishedAt:  finishedAt, </ins> ContainerID: DockerPrefix + dockerID, } if tPath != "" {

If you create a pod with a restart policy of never, and you have a container that fails to start (e.g. you set its command to a nonexistent file), the Kubelet currently tries to restart it infinitely because the container never started successfully, and therefore never received an exit code. You end up with something like this from Docker: Is it worth modifying the code to consider a container that failed to start as actually failed, so the pod's restart policy can govern it? Originally reported at
+1. Also, I'm not sure why we would even apply a restart policy, since the container never started. , Andy Goldstein wrote:
One issue that comes up with marking it failed is if its governed by a Replication Controller, a consequence of marking it Failed is a proliferation of Pods being rapidly created and then failed. I know pod garbage collection would help that, but it would be good if we can update the dependent controller to recognize in common cases to back-off if pods keep failing because of failure to start scenarios. , Vish Kannan wrote:
I thought Kubelet already surfaces both creation and start failure from docker. Let me find the old issue I filed.
Here is the issue and the initial fix is PR: This is a bug we should fix anyway.
what is the output of kubectl describe pods? Are container at waiting state with proper error message from docker?
With respect to replication controller, see also . It should back off.
kubelet does surface the error (see the status below). The problem is that it doesn't categorize the container as dead/terminated, which affects the restart policy. A container would be considered "terminated" in kubelet if its state is not Running and the . In the case where a container failed to start, the FinishedAt time is zero (see example below), and the container state would be . This may cause kubelet to not even back off restarting at all (didn't check thoroughly), let alone complying to the restart policy. We should make sure kubelet categorize these containers properly.
Ok, I reproduced the issue easily. Here are the current situation: When container cannot start by docker due to various reasons, Kubelet marked the container as Waiting state with proper reason (RunContainerError) and detail message for docker, so Pod will stuck at Pending state.

I copied & pasted a PodStatus example below: When above situation occurs, Kubelet will retry in next syncLoop, which is the original issue reported here. Please note that I call this retry, instead of restart, which arguably align with our current , and do nothing. So that upstream layer can pick up such issue, for example, job controller in this case, and delete such bad pods. Or Kubelet can introspect ContainerStatus's reason: With restartPolicy never, Kubelet marks such Container as terminated with above proper reason. With restartPolicy onFailure, Kubelet marks such Container as terminated with above proper reason, and pod stays Running. Retry / Restart will be backoff by the same backoff policy on the node. With restartPolicy Always, Kubelet marks such Container as terminated with above proper reason, and pod stays Running. etry / Restart will be backoff by the same backoff policy on the node. For replication controlled pods, since we didn't mark Pod as Failed, there is no issue mentioned at
I think kubelet should not rely on the reason (which is best-effort), and simply stops relying solely on to categorize "terminated" containers.
what would you look at in addition to ?
in my example above, the container which failed to start had . To me, it's clear that there was a failed attempt trying to start the container. Even though it's finish time is zero, this container should be considered "terminated".
ah, good point! I hadn't noticed that ExitCode was nonzero.


Question: diskName:         diskName, oldSize:          *resource.NewQuantity(1*(1024*1024*1024), resource.BinarySI), newSize:          *resource.NewQuantity(2*(1024*1024*1024), resource.BinarySI), <del> existedDisk:      compute.Disk{Name: to.StringPtr("disk1"), DiskProperties: &compute.DiskProperties{DiskSizeGB: &diskSizeGB}}, </del> <ins> existedDisk:      compute.Disk{Name: to.StringPtr("disk1"), DiskProperties: &compute.DiskProperties{DiskSizeGB: &diskSizeGB, DiskState: compute.Unattached}}, </ins> expectedQuantity: *resource.NewQuantity(2*(1024*1024*1024), resource.BinarySI), expectedErr:      false, },

<!-- 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: resize Azure disk issue when it's in attached state: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: 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: /priority important-soon /sig cloud-provider /area provider/azure /triage accepted /kind bug /assign


Question: HardPodAffinitySymmetricWeight: 1, HealthzBindAddress:             "0.0.0.0:10251", MetricsBindAddress:             "0.0.0.0:10251", <ins> DebuggingConfiguration: componentbaseconfig.DebuggingConfiguration{ EnableProfiling:           true, EnableContentionProfiling: true, }, </ins> LeaderElection: kubeschedulerconfig.KubeSchedulerLeaderElectionConfiguration{ LeaderElectionConfiguration: componentbaseconfig.LeaderElectionConfiguration{ LeaderElect:       true,

What would you like to be : Enable profiling by default in the scheduler. We can do this by defaulting the CC flags to true. Why is this needed: It is useful when debugging the performance of a running cluster. API server already enables profiling by default. /sig scheduling /help /milestone v1.17
/assign /remove-help


Question: export KUBE_CERT="${CERT_DIR}/pki/issued/kubecfg.crt" export KUBE_KEY="${CERT_DIR}/pki/private/kubecfg.key" export CA_CERT="${CERT_DIR}/pki/ca.crt" <del> export CONTEXT="aws_${INSTANCE_PREFIX}" </del> <ins> export CONTEXT="${CONFIG_CONTEXT}" </ins> ( umask 077 create-kubeconfig

I've run to create a cluster, which resulted in a cluster and user being created in kube-config. Now I want to run again with different parameters, to create a second cluster in a different AWS account. I would like to use a different name for the cluster and user for this cluster. From what I can see from the , there seems to be no way to completely override the name used. I understand that I can use a separate kube-config file, but I don't want to do that. I want to use the same kube-config file, with multiple clusters and users, all handled by .
Manually overwriting file to set CONTEXT to a different value works to achieve the effect that I want. This value should be allowed to be set externally so that we don't have to resort to manually editing the file for each cluster.
Fixed in


Question: // newVMSSVirtualMachinesCache instanciates a new VMs cache for VMs belonging to the provided VMSS. func (ss *scaleSet) newVMSSVirtualMachinesCache(resourceGroupName, vmssName, cacheKey string) (*azcache.TimedCache, error) { <ins> if ss.Config.VmssVirtualMachinesCacheTTLInSeconds == 0 { ss.Config.VmssVirtualMachinesCacheTTLInSeconds = vmssVirtualMachinesCacheTTLDefaultInSeconds } vmssVirtualMachinesCacheTTL := time.Duration(ss.Config.VmssVirtualMachinesCacheTTLInSeconds) * time.Second </ins> getter := func(key string) (interface{}, error) { localCache := &sync.Map{} // [nodeName]*vmssVirtualMachinesEntry

<!-- 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: When a node is deleted and then recreated in short time, the "instance not found" error would be reported from Azure cloud provider and hence the node object is deleted by kube-controller-manager. It is because the deleted VMSS VM would be cached for 15 minutes (this is used to avoid throttling issues when a large number of nodes are deleted): The cache above is too long and should be reduced to a shorter value, e.g. 3 minutes. What you expected to happen: The newly created Node should not be deleted. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: 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: /kind bug /priority critical-urgent /area provider/azure /sig cloud-provider
is anyone already working on this?
is working on a fix for this. Would you like to have a look?
will do
Thank you for working on this, and /assign


Question: LG="1"                # amount of load generators SLAVE="1"             # amount of redis slaves TEST="1"              # 0 = Don't run tests, 1 = Do run tests. <del> NS="default"          # namespace </del> <ins> NS="k8petstore"          # namespace </ins> NODE_PORT=30291     #nodePort, see fe-s.json kubectl="${1:-$kubectl}"

During the review of , it's better to also update and to use non-default namespace. cc .
cc
/ , I can continue to work on this one :).
/ , can you help to assign this issue to me? So I can trace the tasks in my hand :).
I'd be happy to assign you once you accept the invitation to the org. Do you plan to work on this now? If you're not actively working on it, I'd prefer to leave it unassigned.
, would you help to send the invitation ? Yes, I'd like to work on this now, that's a good start for me to learn example & e2e test suite :).
Already sent. Visit to accept. See
, I'm kuber now , thanks. I'm working on this now :). Checked and , openshift-origin is not using default namespace now; and we can update 's script to update namespace. But it seems and other example are still using default namespace, should we go through all example and update them accordingly?
, should I update all ns in one commit or one commit per example?
In which examples do you plan to make this change? cc
Making this change in some examples would be useful, but only if we explain why we're doing it. Additionally, linking to existing docs and blogs about namespaces would be helpful: I don't want to do this in all of the examples, because it does add an extra step, and labels also provide a means of managing a group of related resources within a namespace. Perhaps could recommend examples where this would make sense.


Question: } func (r *ScaleREST) Update(ctx context.Context, name string, objInfo rest.UpdatedObjectInfo, createValidation rest.ValidateObjectFunc, updateValidation rest.ValidateObjectUpdateFunc, forceAllowCreate bool, options *metav1.UpdateOptions) (runtime.Object, bool, error) { <del> obj, err := r.store.Get(ctx, name, &metav1.GetOptions{}) if err != nil { return nil, false, err } cr := obj.(*unstructured.Unstructured) const invalidSpecReplicas = -2147483648 // smallest int32 oldScale, replicasFound, err := scaleFromCustomResource(cr, r.specReplicasPath, r.statusReplicasPath, r.labelSelectorPath) if err != nil { return nil, false, err } if !replicasFound { oldScale.Spec.Replicas = invalidSpecReplicas // signal that this was not set before } obj, err = objInfo.UpdatedObject(ctx, oldScale) if err != nil { return nil, false, err } if obj == nil { return nil, false, apierrors.NewBadRequest(fmt.Sprintf("nil update passed to Scale")) } scale, ok := obj.(*autoscalingv1.Scale) if !ok { return nil, false, apierrors.NewBadRequest(fmt.Sprintf("wrong object passed to Scale update: %v", obj)) } if scale.Spec.Replicas == invalidSpecReplicas { return nil, false, apierrors.NewBadRequest(fmt.Sprintf("the spec replicas field %q cannot be empty", r.specReplicasPath)) </del> <ins> scaleObjInfo := &scaleUpdatedObjectInfo{ reqObjInfo:         objInfo, specReplicasPath:   r.specReplicasPath, labelSelectorPath:  r.labelSelectorPath, statusReplicasPath: r.statusReplicasPath, </ins> } <del> specReplicasPath := strings.TrimPrefix(r.specReplicasPath, ".") // ignore leading period if err = unstructured.SetNestedField(cr.Object, int64(scale.Spec.Replicas), strings.Split(specReplicasPath, ".")...); err != nil { return nil, false, err } cr.SetResourceVersion(scale.ResourceVersion) obj, _, err = r.store.Update( </del> <ins> obj, _, err := r.store.Update( </ins> ctx, <del> cr.GetName(), rest.DefaultUpdatedObjectInfo(cr), </del> <ins> name, scaleObjInfo, </ins> toScaleCreateValidation(createValidation, r.specReplicasPath, r.statusReplicasPath, r.labelSelectorPath), toScaleUpdateValidation(updateValidation, r.specReplicasPath, r.statusReplicasPath, r.labelSelectorPath), false,

What happened: Using a command such as: fails with the following error: This bug happens on each run and started occurring as of v1.15.0. With v1.14 or older, I don't have such problem, i.e. it works flawlessly. What you expected to happen: The command succeeds: How to reproduce it (as minimally and precisely as possible): Create a CRD that has the scale subresource and try to scale a CR using . Example of such CRD can be found . Anything else we need to know?: Regarding the bug, it seems that it started appearing as of . Before the PR, we always fetched the resource and it worked because it had the resource version, while now we are only fetching it in case preconditions are provided (preconditions are not provided by default/when using ). Here is the output of a command: If I manually craft the request that has the resource version (or use the flag), it works. Is it as expected that the Scale resource requires the resource version in order for update to succeed? Shouldn't it always pick the latest resource version in case it isn't provided? On that note, I also noticed that if you want to update a CR by crafting the request manually and using , you also need to specify the resource version or you will get the same error. I'm not sure if this is expected and related, but I'm writing it down as it might be related. As far as I know, this is not required for some native resources at all, but I'm not sure is this the case for CRDs. Environment: Kubernetes version (use ):
/sig api-machinery cc
/sub
could you try to see if it fix the problem?
I've created a test cluster based on and I can confirm that I'm able to scale CustomResources using as usual. I used an to test this, such as: Thanks a lot for your time spent fixing this!
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17? I see you move it to 1.17 so I just wanted to be sure.
I guess could be merged now?

It is in the review queue and should still make 1.17
a kind reminder that code freeze for this release is on November 14.
I wanted to circle back around on this. We are 4 days out from code freeze. If this is still good based on just note here. Judging from the looks of it we are still good
Yes this should merge early in the week
Code freeze is tomorrow, this still going to make it?
yes, is still planned


Question: 'net.ipv4.ip_unprivileged_port_start' 'net.ipv4.ip_local_reserved_ports' 'net.ipv4.tcp_keepalive_time' <ins> 'net.ipv4.tcp_fin_timeout' 'net.ipv4.tcp_keepalive_intvl' 'net.ipv4.tcp_keepalive_probes' </ins> */

Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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 node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted