jiebi/CodeConvo huggingface dataset:
Code change:
for _, item := range testCases { stopCh := make(chan struct{}) fakeClientset := fake.NewSimpleClientset(&v1.PodList{Items: item.pods}) <del> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </del> <ins> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{node: item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </ins> controller.recorder = testutil.NewFakeRecorder() go controller.Run(stopCh) controller.NodeUpdated(item.oldNode, item.newNode)

Related discussion:
text: You can sort of get a feel for what's going on here by looking at these two code snippets: This is what happens in when the node does not have any NoExecute taints: If you have any NoExecute taints on the node processPodOnNode gets called and this routine is really, really eager to evict pods. So : We are currently working around this issue by changing over our NoExecute taints to NoSchedule.
/sig scheduling node
/cc
/remove-sig scheduling scheduler isn't involved in this case.
Which SIG owns the controller-manager or is the node lifecycle manager (and its NoExecuteTaintManager) owned by sig-node alone?
I think node lifecycle is jointly owned by sig-node and sig-cloud-provider
API machinery owns the mechanics of the controller manager (controller loop setup and management), but the individual controllers are SIG-specific
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
Looks like we lost some momentum here and I'd like to avoid this falling into the abyss of bugs that never get fixed. When this bug is triggered the outcome is pretty terrible and once it does happen it is very difficult to dig into and understand what actually happened. Did we ever get this routed to the right owner?
adding sig-node leads for triage/routing. this seems like a clearly reproducible bug with significant correctness issues. /assign
thanks for the detailed report and reproducer. to help accelerate this, do you have a form of your reproducer we could add in the e2e suite (even if its failing initially)?
custom taints are considered disruptive, so it couldn't run in the main suite
It's been a while since I wrote tests for the e2e suite but if you are available over slack in case guidance is needed, I'm willing to put the effort.
Do all suites need to pass for a fix to be merged? I'd assume it is the case, otherwise how would a regression be prevented after the fix lands?
Code change:
for _, item := range testCases { stopCh := make(chan struct{}) fakeClientset := fake.NewSimpleClientset(&v1.PodList{Items: item.pods}) <del> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </del> <ins> controller := NewNoExecuteTaintManager(fakeClientset, getPodFromClientset(fakeClientset), (&nodeHolder{node: item.newNode}).getNode, getPodsAssignedToNode(fakeClientset)) </ins> controller.recorder = testutil.NewFakeRecorder() go controller.Run(stopCh) controller.NodeUpdated(item.oldNode, item.newNode)

Related discussion:
text: i was more inquiring if there was a test that could automate the reproduction, so even just a linked commit may be helpful for someone that wants to pick this up. i am happy to help if you want to reach out over slack later this week.
looks like a unit test could reproduce the issue, opened a WIP fix in
our code is not publicly accessible, I'm sorry. PR linked by seems to cover both the fix and the test that proves it.
/remove-lifecycle frozen
frozen keeps the bot from auto-closing
Ah, sorry then.
Code change:
rm.Stop() }) Describe("regular resource usage tracking", func() { <ins> // We assume that the scheduler will make reasonable scheduling choices // and assign ~N pods on the node. // Although we want to track N pods per node, there are N + add-on pods // in the cluster. The cluster add-on pods can be distributed unevenly // among the nodes because they are created during the cluster // initialization. This *noise* is obvious when N is small. We // deliberately set higher resource usage limits to account for the // noise. </ins> rTests := []resourceTest{ {podsPerNode: 0, limits: containersCPUSummary{ <del> "/kubelet":       {0.50: 0.05, 0.95: 0.15}, "/docker-daemon": {0.50: 0.03, 0.95: 0.06}, </del> <ins> "/kubelet":       {0.50: 0.06, 0.95: 0.08}, "/docker-daemon": {0.50: 0.05, 0.95: 0.06}, </ins> }, }, {podsPerNode: 35, limits: containersCPUSummary{ <del> "/kubelet":       {0.50: 0.15, 0.95: 0.35}, "/docker-daemon": {0.50: 0.06, 0.95: 0.30}, </del> <ins> "/kubelet":       {0.50: 0.12, 0.95: 0.14}, "/docker-daemon": {0.50: 0.06, 0.95: 0.08}, </ins> }, }, }

Related discussion:
text: It fails all the time in . cc
I suspect the node was in a bad state. After deploying the new build, the test hasn't failed at all this week. Closing this and will re-open if it hits again.
It's failing again: and so on.
cc
The 0 pods per node test is more sensitive to noise caused by uneven distribution of cluster add-on pods. I adjusted the limits in to reflect the current kubelet status and also to account for the noise. Ideally we should disable the cluster add-ons in the cluster, but there is no easy way to do this in the current test framework. I think we should consider moving this test with hard limits to the node conformance test suite (where the addons are not enabled). We can keep this test here for monitoring purpose, but don't fail the build explicitly. We can integrate with other monitoring service and send alerts if necessary.
- actually it is easy to do during cluster startup. We can create a dedicated Node suite and run Node tests there (if it's not done already).
we actually just started node conformance tests in , which one of the v1.2 targets. It seems like this test might be a good fit there. cc will know more about porting/migrating tests to the node conformance suites.
Yes, one of the reasons we create a separate node test suite is moving this kind of test over. Let's try to move all node level resource tracking tests over to node test suite.
failing in https://k8s- https://k8s-
[FLAKE-PING] This flaky-test issue would love to have more attention.
This issue is not intended for GCI nor upgrade suites. Filing a new issue might be better. GCI has had problems with the docker memory usage for a while, as you can see in https://k8s- I think they fixed it in the latest dev image, but I am not sure if that was used in the upgrade tests.
Code change:
//       Above tests are performed by doSheduletTests() and doPodResizeResourceQuotaTests() //       in test/node/pod_resize_test.go <del> var _ = SIGDescribe("Pod InPlace Resize Container", framework.WithSerial(), feature.InPlacePodVerticalScaling, func() { </del> <ins> var _ = SIGDescribe("Pod InPlace Resize Container", framework.WithSerial(), feature.InPlacePodVerticalScaling, "[NodeAlphaFeature:InPlacePodVerticalScaling]", func() { </ins> if !podOnCgroupv2Node { cgroupMemLimit = CgroupMemLimit cgroupCPULimit = CgroupCPUQuota

Related discussion:
text: /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
could be related to
/assign
Yes, tests should be skipped with Feature:InPlacePodVerticalScaling on those CIs , it fails because InPlacePodVerticalScaling is not enabled. Will update tomorrow morning, checking more closely how to fix in a smooth way
Thanks , It was failing in 11 jobs for two reasons: In 7 jobs because InPlacePodVerticalScaling was not supported and was missed to identify, attempt to fix by because all impacted CI jobs will skip tests with labels with prefix NodeAlphaFeatures In 4 jobs because Arm64 was not checked in one test, attempt to fix by
Code change:
} bhash := sha256.New().Sum(body) <del> // Port in the signature must be that of the reverse proxy port, vCenter's default is port 80 port := "80" // TODO: get from lookup service </del> <ins> port := req.URL.Port() if port == "" { port = "80" // Default port for the "Host" header on the server side } </ins> var buf bytes.Buffer msg := []string{ nonce,

Related discussion:
text: <!-- 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: The vSphere cloud provider is unable to fetch the node failure domain labels when using VCP with SAML auth because of an authentication failure. For context, the SAML token auth is described here - SAML auth support for the zones api was introduced in this PR - , which was cherry-picked to 1.14.1 here - I've tested the credentials I'm using with govc to ensure that I'm able to get a token: The credentials also work fine when using VCP without the node labels feature. Relevant kubelet logs: What you expected to happen: VCP should add failure domain labels to the node object. How to reproduce it (as minimally and precisely as possible): Setup SAML auth for VCP with zone labeling enabled. Anything else we need to know?: There was a previous issue that was raised () but that was before SAML auth support for zones was implemented. This could potentially be an issue with govc handling of SAML tokens since even with the Administrator role assigned to the user, I'm still unable to list tags. The role and keys were generated with the following: Environment: Kubernetes version (use ): 14.1 Cloud provider or hardware configuration: vSphere OS (e.g: ): Linux & Windows
/sig vmware
Would you mind taking a look at this? I can provide more info if needed.
govc's command only works with the SOAP endpoint currently. The REST endpoint has its own session manager and requires a separate login. At the moment, govc's tags commands login/logout when each command is run and don't use a persisted session (which are saved to ~/.govmomi/sessions). However, you can use a token returned by to test SAML auth with the tags commands. For example: Can you give that try? There are some TODOs around this btw:
Those commands work for me. So that would imply the solution user, role, and permissions are set up correctly? Would you expect the to also work?
Code change:
} bhash := sha256.New().Sum(body) <del> // Port in the signature must be that of the reverse proxy port, vCenter's default is port 80 port := "80" // TODO: get from lookup service </del> <ins> port := req.URL.Port() if port == "" { port = "80" // Default port for the "Host" header on the server side } </ins> var buf bytes.Buffer msg := []string{ nonce,

Related discussion:
text: I seem to be getting a 404 when using with the flag - Does seem to work when specifying a tag name: Are there any other govc commands I should check / verify?
yes, the solution user setup looks right. Not sure what the issue is with . Can you share your vCenter build number ()? I'll try to reproduce the issue.
$ govc about -u vcdo Name: VMware vCenter Server Vendor: VMware, Inc. Version: 6.7.0 Build: OS type: linux-x64 API type: VirtualCenter API version: 6.7.2 Product ID: vpx UUID: -55ed-4737-9cc4-
I can reproduce this, but don't know what the issue is yet. The version of Go and vSphere have changed since , but if it was one of those was the cause, I'd expect SAML auth to fail with the govc tags commands too. All I have to go on for now is the vCenter log message below. I'll update when I have more info.
I have it working with the change below, but need to figure out a few things first: Why this is the case when run inside kubelet and not govc (note that the port change to 443 breaks govc) A good way to determine which port to use (depends on the answer to the above) If this is behavior is specific to 6.7U2 or something triggered by a change in K8s I suppose a quick fix would change to try port 443 if 80 fails, but would prefer to avoid that as the failure generates stack traces in the
/assign
This is obvious in retrospect, but the issue is the message signature needs to use the same port as the original request URL. However, in the govc case there was no port set in the request URL. The client defaults to port when connecting (based on the scheme), but does not include any port with the header. In the case, the default is on the server side. This can be reproduced with if includes the port , rather than just as we were using. The VCP tests that use token auth for tags lookup just don't validate the signature, so this wasn't a change related to 6.7U2.
Code change:
} bhash := sha256.New().Sum(body) <del> // Port in the signature must be that of the reverse proxy port, vCenter's default is port 80 port := "80" // TODO: get from lookup service </del> <ins> port := req.URL.Port() if port == "" { port = "80" // Default port for the "Host" header on the server side } </ins> var buf bytes.Buffer msg := []string{ nonce,

Related discussion:
text: I'll open a K8s PR to pull in the fix:
Updating k/vendor to govmomi master adds almost 6K lines for a 3 line fix. I may just create a govmomi branch off of v0.20 to reduce churn in the K8s release branches for this fix, may have to wait until tomorrow.
Really appreciate the insight into this issue. Can confirm that specifying the port (443) in the GOVC_URL reproduces the issue. Thank you!
Unfortunately, I'm seeing the same issue with v1.14.3: cloud_config Works fine when I use the username and password of a vsphere admin, but using cert and key still has authentication issues.
any related errors in vCenter's ?
Seeing a lot of this exception:
whoa! that stack trace is like punch in the gut (brings back memories!) :)
indeed!! apologies, I must have had the change for PR locally, but failed to include it as I had focused on the signature issue and updating vendor/
Code change:
See the [limitRange design doc](../design/admission_control_limit_range.md) and the [example of Limit Range](limitrange/) for more details. <del> ### NamespaceExists </del> <ins> ### NamespaceExists (deprecated) </ins> This plug-in will observe all incoming requests that attempt to create a resource in a Kubernetes `Namespace` and reject the request if the `Namespace` was not previously created.  We strongly recommend running this plug-in to ensure integrity of your data. <ins> The functionality of this admission controller has been merged into `NamespaceLifecycle` </ins> ### NamespaceAutoProvision (deprecated) This plug-in will observe all incoming requests that attempt to create a resource in a Kubernetes `Namespace` and create a new `Namespace` if one did not already exist previously. <del> We strongly recommend `NamespaceExists` over `NamespaceAutoProvision`. </del> <ins> We strongly recommend `NamespaceLifecycle` over `NamespaceAutoProvision`. </ins> ### NamespaceLifecycle <del> This plug-in enforces that a `Namespace` that is undergoing termination cannot have new objects created in it. </del> <ins> This plug-in enforces that a `Namespace` that is undergoing termination cannot have new objects created in it, and ensures that requests in a non-existant `Namespace` are rejected. </ins> A `Namespace` deletion kicks off a sequence of operations that remove all objects (pods, services, etc.) in that namespace.  In order to enforce integrity of that process, we strongly recommend running this plug-in. <del> Once `NamespaceAutoProvision` is deprecated, we anticipate `NamespaceLifecycle` and `NamespaceExists` will be merged into a single plug-in that enforces the life-cycle of a `Namespace` in Kubernetes. </del> ## Is there a recommended set of plug-ins to use? Yes.

Related discussion:
text: We should have a single NamespaceLifecycle plugin that enforces the Namespace rules now that all providers are off NamespaceAutoProvision. We may also want to make this no longer a user choice to configure and hard-wire the server to always run this check first to simplify configuration errors. For an example
Code change:
"net.ipv4.ip_local_port_range", "net.ipv4.tcp_syncookies", "net.ipv4.ping_group_range", <ins> "net.ipv4.ip_unprivileged_port_start", </ins> } }

Related discussion:
text: Is the sysctl namespaced? If so, can we include this in the set of "safe" sysctls? If we allow this, we would: add to permit in PodSecurity baseline profile cc So that containers can bind to low ports without needing to bake CAPNETBINDSERVICE into the files in the image doesn't help hostNetwork pods since they don't have their own namespace and you likely wouldn't want to change the system-wide sysctl also, pods that schedule to arbitrary nodes likely shouldn't start taking advantage of this until 2+ releases after it merges into the kubelet, because of potential node skew
/sig network security node auth
xref: for actually potentially setting this by default even.
/assign
Yes, it is network-namespaced and :+1: to adding it to safe list. From
/triage accepted
Code change:
"//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", <ins> "//staging/src/k8s.io/component-base/featuregate:go_default_library", </ins> "//staging/src/k8s.io/component-base/featuregate/testing:go_default_library", "//vendor/github.com/stretchr/testify/assert:go_default_library", ],

Related discussion:
text: 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.
Code change:
"//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", <ins> "//staging/src/k8s.io/component-base/featuregate:go_default_library", </ins> "//staging/src/k8s.io/component-base/featuregate/testing:go_default_library", "//vendor/github.com/stretchr/testify/assert:go_default_library", ],

Related discussion:
text: /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]:
Code change:
update-generated-docs update-generated-swagger-docs update-openapi-spec <del> update-bazel </del> update-gofmt" for t in ${BASH_TARGETS}; do

Related discussion:
text: This is intended to be removed once there are no active branches with bazel. 1.19 was still supported last I checked. We have some other cleanup pending the final turndown of bazel branches.
19 just had it's last patch release a week ago , these are removed now.
Code change:
# TODO: Re-enable race detection when we switch to a thread-safe etcd client # KUBE_RACE="-race" make -C "${KUBE_ROOT}" test  <del> WHAT="$(kube::test::find_integration_test_dirs | paste -sd' ')"  </del> <ins> WHAT="$(kube::test::find_integration_test_dirs | paste -sd' ' -)"  </ins> KUBE_GOFLAGS="${KUBE_GOFLAGS:-} -tags 'integration no-docker'"  KUBE_RACE=""  KUBE_TIMEOUT="${KUBE_TIMEOUT}" 

Related discussion:
text: I don't know where the at the beginning of the target comes from, but probably from assumptions about sed version that are wrong. I had to update to gnu-sed 4.2.2 to build.
Also ootb on a Mac doesn't work with the rules specified (on el capitan):
does work
I take it back - updating sed did not appear to work. EDIT: I take that back, I had to clean after fixing paste.
most recent OSX version is UNIX certified, a POSIX requires as file argument when reading input from stdin. For , is only guaranteed to work in GNU sed, you need to insert literal newline and tab character there for portability.
Can someone with a mac send a patch? I don't have a mac...
It's update and every should end in instead of having no arguments. , Tim Hockin wrote:
(user should update sed, make needs changes to paste) , Clayton Coleman wrote:
I think we should stick to portable way for , it's too risky for relying on GNUism. If you don't mind, I will make a PR.
Sure, thanks , Cuong Manh Le wrote:
Are you sure the worked? I pull the latest from master, then run the same command above, I got: File is empty.
Make sure you are in your GOPATH in the correct spot for Kube On Jul 14, 2016, at 2:47 AM, Cuong Manh Le wrote: Are you sure the Makefile worked? I pull the latest from master, then run the same command above, I got: F0714 13:36:50. ] Error: Failed making a parser: unable to add directory "": unable to import "": expected 'package', found 'EOF' make: * [Makefile.generatedfiles:201: gendeepcopy] Error 255 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
If you get the "expected 'package', found 'EOF'" message it is usually because something somewhere failed, and left an empty .go file. make cleangenerated , Cuong Manh Le wrote:
From BSD sed man page: Maybe try that?
It's not about ERE ( enables it), it's about expanding escape sequences in RHS of search and replace .