jiebi/CodeConvo huggingface dataset:
Change:
return namespaces } <ins> func createClients(numberOfClients int) ([]*client.Client, error) { clients := make([]*client.Client, numberOfClients) for i := 0; i < numberOfClients; i++ { config, err := framework.LoadConfig() Expect(err).NotTo(HaveOccurred()) config.QPS = 100 config.Burst = 200 if framework.TestContext.KubeAPIContentType != "" { config.ContentType = framework.TestContext.KubeAPIContentType } // For the purpose of this test, we want to force that clients // do not share underlying transport (which is a default behavior // in Kubernetes). Thus, we are explicitly creating transport for // each client here. transportConfig, err := config.TransportConfig() if err != nil { return nil, err } tlsConfig, err := transport.TLSConfigFor(transportConfig) if err != nil { return nil, err } config.Transport = utilnet.SetTransportDefaults(&http.Transport{ Proxy:               http.ProxyFromEnvironment, TLSHandshakeTimeout: 10 * time.Second, TLSClientConfig:     tlsConfig, MaxIdleConnsPerHost: 100, Dial: (&net.Dialer{ Timeout:   30 * time.Second, KeepAlive: 30 * time.Second, }).Dial, }) // Overwrite TLS-related fields from config to avoid collision with // Transport field. config.TLSClientConfig = restclient.TLSClientConfig{} c, err := client.New(config) if err != nil { return nil, err } clients[i] = c } return clients, nil } </ins> func computeRCCounts(total int) (int, int, int) { // Small RCs owns ~0.5 of total number of pods, medium and big RCs ~0.25 each. // For example for 3000 pods (100 nodes, 30 pods per node) there are:

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
We understand the problem here - I'm working on the fix.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apiserver/pkg/authentication/user" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" </ins> rbac "k8s.io/kubernetes/pkg/apis/rbac" <ins> "k8s.io/kubernetes/pkg/features" </ins> ) var (

Discussion:
/kind feature From: Would it make sense to add these rules to the bootstrappolicy? To me they seem generic enough, and they wouldn't bind to something. Consumers can do the binding to their subjects as they like. I'm asking because it's already duplicated twice for two early adopters: I don't think those ClusterRoles are specific to kubeadm and GKE at all; but the ClusterRoleBindings will surely be, so therefore we'd create the roles but not the bindings.
Wouldn't we expect and encourage people using the CSR capability for their nodes to use node identities that match the node authorizer, in which case we won't need the client or server renewal CSR roles?
The node authorizer doesn't grant these, since otherwise you could never prevent a compromised node from renewing its credentials
Realistically, with these roles you still wouldn't. People would grant them to the node group, not each individual node, but I guess that would be a tradeoff for the deployment mechanism.
You could individually revoke this role from the group and stop renewals without disrupting regular operation
I can definitely see myself revoking a binding from to multiple specific bindings in case of a compromise. Anyway, this issue is more "should we create these by default or not". I've already mentioned my opinion.
Creating the roles seems reasonable. I don't think I want bindings. I think the binding should be up the particular deployer.
Perfect, that's exactly my proposal. I'll go ahead and make this change...
/assign
are you working on this or should I send a PR?
Change:
- endpoint: replaceNetworkingV1NamespacedNetworkPolicyStatus reason: endpoints is currently feature gated and and will only receive e2e & conformance test in 1.25 link: https://github.com/kubernetes/kubernetes/pull/107963 <ins> - endpoint: readCoreV1NodeStatus reason: Kubernetes distribution would reasonably not allow this action via the API link: https://github.com/kubernetes/kubernetes/issues/109379 - endpoint: replaceCoreV1NodeStatus reason: Kubernetes distribution would reasonably not allow this action via the API link: https://github.com/kubernetes/kubernetes/issues/109379 - endpoint: deleteCoreV1CollectionNode reason: Kubernetes distribution would reasonably not allow this action via the API link: https://github.com/kubernetes/kubernetes/issues/109379 </ins>

Discussion:
In the K8s Conformance meeting of 6 April the testing of Node endpoints and their eligibility for conformance testing was discussed. This issue is created to get more community input on the topic. Should node endpoints be tested? Can we accualy test these endpoints with the current test framework /sig testing /sig architecture /area conformance
/triage accepted /cc
I have lost track of this issue where it have already been discussed. Let's continue to discuss further here. Apologies for the confusion /cc
Clayton We have historically focused conformance on the perceived end user experience deploying applications to a conformant Kubernetes cluster as being consistently successful. From that perspective, while these are actions that are indeed key to conformant behavior on the majority of distributions, the first two are not invoked by end users, only by kubelets and potentially administrators in rare cases. I would expect to be able to create a node object, delete it, mutate its status, and delete a portion of them on a conformant Kubernetes cluster as an admin - but I would not expect a similar end user to do so. If we can make a case that a conformant Kubernetes distribution would reasonably not allow any of these actions via the API, then we could make a case to omit them from conformance. I can see a small path to adding these to conformance under a "they may be necessary as administrative action on the vast majority of kubernetes clusters", but I can't necessarily bump that to 100% of Kube clusters, especially if we put the application deployer as the center of our story (an application deployer does not need to delete node collections in order to succeed at running an application on conformant kubernetes)
Addressed the question in SIG Node
Created to make the remaining node endpoints ineligible. readCoreV1NodeStatus replaceCoreV1NodeStatus deleteCoreV1CollectionNode
Change:
// perform any validation. // According to our measurements this is significantly faster // in codepaths that matter at high scale. <ins> // Note: this method copies the Set; if the Set is immutable, consider wrapping it with ValidatedSetSelector // instead, which does not copy. </ins> func (ls Set) AsSelectorPreValidated() Selector { return SelectorFromValidatedSet(ls) }

Discussion:
A common pattern in Kubernetes (both internally and in third party usage) is something like: (this is from the ). This is commonly called at a fairly high rate; in our case we would actually end up seeing this account for significant portions of CPU/memory to compute the and run on it. In our controller, as an optimization, we replaced usage of and just used our own simpler label matching code, leading to a 70% speed up in our function (which does more than just match) and 96% allocation size improvement; see I believe similar could be done in Kubernetes directly by having a specialized Selector implementation for simple labels. This would transparently given substantial performance benefits to anyone using the library
/sig api-machinery
is the change here a new kind of selector matching or a tweak to something existing? It's hard to tell if this is proposing a new design to partition types of selectors that needs a kep versus a perf tweak to existing code that is straight-forward.
The proposal is an internal performance improvement to make a specialized implementation of the selector matching internally. So two concrete implementations for 1 shared interface. is a PoC of this. I think it can be extended (by me, or others if someone wants to) to complete it
We discussed this one during our bug triage. There seemed to be the feeling that this is large enough to need a KEP? Would you be up for that? Additionally you could bring it up in our SIG meeting to socialize / discuss it more if you wanted.
The patch shared in helps to explain, it's a lot smaller than the description made it sound. This is a special case for equality-only selectors. Probably still worth bringing up at a sig-meeting, but if if the patch is a good representation, it is more bounded than expected from the issue description.
/triage accepted
Change:
nodeMaxAllocatable = allocatable.MilliValue() } } <del> framework.WaitForStableCluster(cs, masterNodes) </del> <ins> // Clean up added labels after this test. defer func() { for nodeName := range nodeToAllocatableMap { framework.RemoveLabelOffNode(cs, nodeName, "node") } }() </ins> pods, err := cs.CoreV1().Pods(metav1.NamespaceAll).List(metav1.ListOptions{}) framework.ExpectNoError(err)

Discussion:
cc cc Seeing a failure on our downgrade test. Can someone please look at this? https://k8s- Example failure https://k8s- Seeing timeouts on the downgrade test
Since we're so late in the release process and this is the first time we're seeing this fail, going to mark as non-release-blocking for now.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/scheduling: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
It fails in more places than just the downgrade job, but when the downgrade job fails that test, that timeout appears to be the consistent error that it fails with
/assign I looked at the logs. The test creates a few pods to saturate the existing nodes and then creates an additional pod and ensures that this last pod stays pending. The problem we observe is that those saturating pods are often not scheduled, causing a test timeout. Those pods use all the resources on the nodes. So, any small changes to the amount of available node resources or even rounding errors could cause those saturating pods to not schedule. I will test this theory by cutting down the amount of resources that the saturating pods use, but I would like to check if the problem is fixed before submitting the PR. Where can I get the steps these cluster downgrade tests take?
The test setups are in the test-infra repo. E.g.
see my analysis in .
Change:
{ Key:      nodeAffinityKey, Operator: v1.NodeSelectorOpIn, <del> Values:   []string{string(i)}, </del> <ins> Values:   []string{fmt.Sprintf("%v", i)}, </ins> }, }, },

Discussion:
What keywords did you search in Kubernetes issues before filing this one? scheduler_perf. Is this a BUG REPORT or FEATURE REQUEST? Bug Kubernetes version (use ): Master Looks like perf test is broke. I'll dig into the details. Leads to Will add more details later or issue a PR if its something trivial.
i think your affinity cleanup patch, might be the source :) .... [ deleted above comment not relevant ] some other change, possibly in the affinity cleanup may have caused this, but i dont think its the stuff, that looks ok to me. Possibly just a typo might have been introduced in that patch? If not maybe its just an issue with the way we need to update the labelling json or something. I can take another look in the morning.
ok, i think i see... it wants to match the label ... from this node: into this set so the set is empty. I guess it could be a bug in the way the match selector is being produced, but the code looks clean to me. will double check.
fixed
Change:
} t.Logf("Found ExternalID(%s) = %sn", srvs[0], externalId) <ins> nonExistingVM := rand.String(15) externalId, err = i.ExternalID(nonExistingVM) if err == cloudprovider.InstanceNotFound { t.Logf("VM %s was not found as expectedn", nonExistingVM) } else if err == nil { t.Fatalf("Instances.ExternalID did not fail as expected, VM %s was found", nonExistingVM) } else { t.Fatalf("Instances.ExternalID did not fail as expected, err: %v", err) } </ins> instanceId, err := i.InstanceID(srvs[0]) if err != nil { t.Fatalf("Instances.InstanceID(%s) failed: %s", srvs[0], err) } t.Logf("Found InstanceID(%s) = %sn", srvs[0], instanceId) <ins> instanceId, err = i.InstanceID(nonExistingVM) if err == cloudprovider.InstanceNotFound { t.Logf("VM %s was not found as expectedn", nonExistingVM) } else if err == nil { t.Fatalf("Instances.InstanceID did not fail as expected, VM %s was found", nonExistingVM) } else { t.Fatalf("Instances.InstanceID did not fail as expected, err: %v", err) } </ins> addrs, err := i.NodeAddresses(srvs[0]) if err != nil { t.Fatalf("Instances.NodeAddresses(%s) failed: %s", srvs[0], err)

Discussion:
ExternalID/InstanceID do not return 'cloudprovider.InstanceNotFound' error when the VM is not found. This can occur when a node VM is deleted entirely. In this case InstanceID method would throw an nil pointer exception here: since returned error here: is not being handled, vm would be nil. vm object is then dereferenced in getVirtualMachineManagedObjectReference func. In ExternalID method, the error is being handled by just passing it up. Node controller then prints out error and continues: e.g. ExternalID/InstanceID should handle the 'nod found' error being returned from vCenter and return 'cloudprovider.InstanceNotFound'.
Change:
func TestPatchPodStatus(t *testing.T) { tests := []struct { <del> name           string pod            v1.Pod </del> <ins> name   string pod    v1.Pod client *clientsetfake.Clientset // validateErr checks if error returned from PatchPodStatus is expected one or not. // (true means error is expected one.) validateErr    func(goterr error) bool </ins> statusToUpdate v1.PodStatus }{ { <del> name: "Should update pod conditions successfully", </del> <ins> name:   "Should update pod conditions successfully", client: clientsetfake.NewSimpleClientset(), </ins> pod: v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Namespace: "ns",

Discussion:
If there is a connection failure when updating the Pod status, we don't retry. Furthermore, due to , we won't have another chance until much later. The problem is that if we don't mark the Pod as Unschedulable, other controllers (such as cluster-autoscaler) wouldn't react to these pods. We should have stronger guarantees to mark a Pod as Unschedulable. You need an unschedulable Pod (for example, a Pod with a non matching node affinity) and a flaky connection to apiserver. No response master This is particularly problematic in 1.24, due to . Any <details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
That is bad, retrying in place on transient errors should probably be ok.
I'll address it. /assign
Thanks!
Change:
if err != nil { t.Errorf("Unxpected error when syncing jobs, got %v", err) } <del> ch := make(chan interface{}) go func() { item, _ := manager.queue.Get() ch <- item }() select { case key := <-ch: expectedKey := getKey(job, t) if key != expectedKey { t.Errorf("Expected requeue of job with key %s got %s", expectedKey, key) } case <-time.After(controllerTimeout): manager.queue.ShutDown() t.Errorf("Expected to find a job in the queue, found none.") </del> <ins> t.Log("Waiting for a job in the queue") key, _ := manager.queue.Get() expectedKey := getKey(job, t) if key != expectedKey { t.Errorf("Expected requeue of job with key %s got %s", expectedKey, key) </ins> } }

Discussion:
Ran a test executable with more than 20,000 times and no failures. Any hints as to how to get it to show up? I'm running 100 jobs at a time, so my system is stressed already.
I to am unable to reproduce this. I get similar errors if I reduce the timeout at the top of the file. I spent a bit looking at how to rewrite the tests without the timeout, but nothing jumped out at me. Looking at it though, it's really just a 500ms timeout for the test to complete. I'm just going to remove them. Go has a default timeout of 10 minutes. If it's going to pass, it will pass then. If not, Go will give you a nice traceback where it deadlocked.
Change:
if len(list.Items) > 1 { return cmdutil.UsageError(cmd, "%s specifies multiple items", filename) } <ins> if len(list.Items) == 0 { return cmdutil.UsageError(cmd, "please make sure %s exists and is not empty", filename) } </ins> obj = list.Items[0] } newRc, ok = obj.(*api.ReplicationController)

Discussion:
For example
This is with recent kubectl:
I think this is a duplicate, but just in case.
I will double check this.
Thanks - it isn't a big deal, because I obviously didn't intend to rolling update to an empty manifest :-) (I was experimenting with templating my manifests and made an error) But let me know if you need any more info to reproduce!
Change:
// UnmountDevice is part of the volume.Detacher interface. func (d *flexVolumeDetacher) UnmountDevice(deviceMountPath string) error { <del> if pathExists, pathErr := util.PathExists(deviceMountPath); pathErr != nil { return fmt.Errorf("Error checking if path exists: %v", pathErr) } else if !pathExists { </del> <ins> pathExists, pathErr := util.PathExists(deviceMountPath) if !pathExists { </ins> glog.Warningf("Warning: Unmount skipped because path does not exist: %v", deviceMountPath) return nil } <ins> if pathErr != nil && !util.IsCorruptedMnt(pathErr) { return fmt.Errorf("Error checking path: %v", pathErr) } </ins> notmnt, err := isNotMounted(d.plugin.host.GetMounter(d.plugin.GetPluginName()), deviceMountPath) if err != nil { <del> return err </del> <ins> if util.IsCorruptedMnt(err) { notmnt = false // Corrupted error is assumed to be mounted. } else { return err } </ins> } if notmnt { glog.Warningf("Warning: Path: %v already unmounted", deviceMountPath) } else {

Discussion:
/kind bug What happened: Kubelet failed to unmount volumes if the backend ISCSI volume is not available. This also applies to other network attached volumes. What you expected to happen: Kubelet should be able to unmount the volumes. A manual unmount works even when the backend network volume is not available. How to reproduce it (as minimally and precisely as possible): Mount an ISCSI/network volume and disconnect/de-provision ISCSI target. Anything else we need to know?: XFS shuts down the filesystem due to I/O errors. Kubelet uses "stat" calls to figure out if it is a valid mount point or it is already unmounted. Stat calls fail with EIO and Kubelet never proceeds to unmount the volume. Environment: Kubernetes version (use ): Kubernetes 1.10.5 Cloud provider or hardware configuration: Bare metal OS (e.g. from /etc/os-release): Centos 7.4 Kernel (e.g. ): Linux appserv37 3.10.0-693.el7.x8664 SMP Tue Aug 22 21:09:27 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Manual bring up Others:
/sig storage
IsLikelyNotMountPoint is using stat call to figure the filesystem is mounted or not. Stat calls are failing with EIO when there are I/O errors on the backend and Kubelet never proceeds to unmount the filesystem. Also, isLikelyNotMountPoint is not looking for "isCorruptedMnt" errors. All other calls have it.
looks like the nfs plugin is calling . Can iscsi use that?
didn't include error "Input/output error" () We should add it. I make a fix, PTAL, Thank you!
Thanks. Trying out the change. Will keep you posted if we need any other changes.
Stock ISCSI driver is working fine with EIO change. But more changes are required for making it work with Flexvolume drivers. I have the change list. I can club your change in or let me know if you want to go ahead and push this fix. I will push another PR to fix flexvolume issues.
Please club my change, I will close my PR. Thanks!
Change:
// nothing provided by user, use default range (only applies to the Primary) if len(serviceClusterIPRangeList) == 0 { var primaryServiceClusterCIDR net.IPNet <del> serviceIPRange, apiServerServiceIP, err = master.DefaultServiceIPRange(primaryServiceClusterCIDR) </del> <ins> serviceIPRange, apiServerServiceIP, err = master.ServiceIPRange(primaryServiceClusterCIDR) </ins> if err != nil { return options, fmt.Errorf("error determining service IP ranges: %v", err) }

Discussion:
API server defaults the service CIDR. We should instead just fail if it is not specified. Defaulting is a wild guess and very likely to be wrong. /sig network /kind bug
For existing clusters that don't currently set it, is setting it to anything other than the current default a breaking change?
Yes. You can not really change it (well, you can expand it, but not totally move it), unless you delete ALL services, including kubernetes.default. I filed this aspirationally. It's not on fire, it's just a dumb thing to have provided a default for.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
minAffinitySize = mask.Count() } <ins> // the node already in group with another node, it can not be used for the single NUMA node allocation if singleNUMAHint && len(machineState[maskBits[0]].Cells) > 1 { return } for _, nodeID := range maskBits { // the node already used for the memory allocation if !singleNUMAHint && machineState[nodeID].NumberOfAssignments > 0 { // the node used for the single NUMA memory allocation, it can not be used for the multi NUMA node allocation if len(machineState[nodeID].Cells) == 1 { return } // the node already used with different group of nodes, it can not be use with in the current hint if !areGroupsEqual(machineState[nodeID].Cells, maskBits) { return } } } </ins> // verify that for all memory types the node mask has enough free resources for resourceName, requestedSize := range requestedResources { podReusableMemory := p.getPodReusableMemory(pod, mask, resourceName)

Discussion:
Setup: 3 Master nodes and 2 Worker Nodes. Version: v1.22.0-rc.0+ Memory Manager on Kubernetes Version (v1.22.0-rc.0+) and Nodes configured with Hugepages of size 2M on 2 Worker nodes. Worker node having 2 Numa Nodes (numa node0 and numa node1) of Hugepages of size 2M are 10 on each Numa node sh-4.4# cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nrhugepages 10 sh-4.4# cat /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nrhugepages 10 After configuring Memory , where Hugepages are 20M (2M * 10) on each Numa node. we create QoS pod1 pod which consumes 24Mi Hugepages (of size 2M) Pod Spec: List pods Memory Manager state file: Now create a QoS Guaranteed Pod2 requesting 16Mi . On the same worker node. Pod spec: List pods: Memory Manager state file after pod2 is deployed. Pod2 should be rejected. Steps provided above Kubernetes version (use ): v1.22.0-rc.0+ Cloud provider or hardware configuration: Openshift OS (e.g: ):Red Hat Enterprise Linux CoreOS release 4.9 Kernel (e.g. ): Linux 4.18.0-305.12.1.rt7.84.el84.x8664 SMP PREEMPTRT Thu Jul 29 14:18:12 EDT 2021 x8664 x8664 x8664 GNU/Linux Kubelet configuration
/triage accepted /priority important-longterm /sig node /area kubelet
/assign