jiebi/CodeConvo huggingface dataset:
Change:
framework.ExpectNoError(err) eps2 := epsTemplate.DeepCopy() eps2.Endpoints = []discoveryv1.Endpoint{ <del> {Addresses: []string{pod2.Status.PodIP}}, </del> <ins> { Addresses:  []string{pod2.Status.PodIP}, Conditions: discoveryv1.EndpointConditions{Ready: &readyCondTrue}, }, </ins> } eps2.Ports = []discoveryv1.EndpointPort{{ Name:     pointer.String("port81"),

Discussion:
The test create custome EndpointSlices to validate some behaviors sending traffic, so it is clear that it expects the EndpointSlices to be ready, The API doc is vague about this situation and leaves room to interpret the "unknown behavior", quoting Since the test expects the EndpointSlices to be Ready we should set them, if we decide to change the API behavior, then we should add an additional e2e test to validate this behavior, but not use the same test to validate two different things /kind bug /kind failing-testing /sig network Slack thread
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : The test create custome EndpointSlices to validate some behaviors sending traffic, so it is clear that it expects the EndpointSlices to be ready, /kind failing-testing /sig network Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
GitHub didn't allow me to assign the following users: aauren. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Thanks I'll take this one and draft up a PR this weekend. (this comment should hopefully allow the k8s ci robot to assign this to me as well)
if you are planning to contribute more often you should apply as org member
Change:
// Invalidate the cache right after updating defer as.cloud.vmCache.Delete(vmName) <del> return as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM, "detach_disk") </del> <ins> return as.VirtualMachinesClient.Update(ctx, nodeResourceGroup, vmName, newVM, "detach_disk") </ins> } // GetDataDisks gets a list of data disks attached to the node.

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Instead of using the VM CreateOrUpdate () function of the Azure Go SDK, use the VM Update function () in the azureclient () Why is this needed: Currently, the Azure Cloud Provider is using the VM CreateOrUpdate call when e.g. detach/attaching disks to a VM. In some scenarios, this will re-create a VM that was deleted by an external application. This can lead to orphaned VMs or blocked resources. The Update function will only update an existing VM and will fail if the VM does not exist.
/sig azure
/assign
/sig cloud-provider
Could you describe more about the scenarios? Have you noticed such issues? I wonder adding etags to the API call could help to prevent this?
If you have an application that maintains your K8s clusters, e.g. takes care of OS update/patching. If the application wants to patch the OS of a worker node, it would drain the node first. If draining times out, it will go ahead and delete the VM anyway. But K8s might still be detaching disks. These detach operations, because they use CreateOrUpdate, will recreate the VM. Is there a reason why you would want to create a VM i.e. why CreateOrUpdate is required and Update would not work? AFAIK, Azure Compute RP does not support etags.
that sounds reasonable, thanks change to use function would be safer since it's only detach/attach disk operation. I will do that.
thanks for the information. Reasonable enough. /assign
/milestone v1.16
BTW, the reason why we only use func in the beginning is that Azure Compute go sdk did not provide a func at that time...
Great. Thanks!
Change:
) const ( <del> dockerProcessName     = "dockerd" </del> <ins> dockerProcessName = "dockerd" // dockerd option --pidfile can specify path to use for daemon PID file, pid file path is default "/var/run/docker.pid" </ins> dockerPidFile         = "/var/run/docker.pid" <del> containerdProcessName = "docker-containerd" containerdPidFile     = "/run/docker/libcontainerd/docker-containerd.pid" </del> <ins> containerdProcessName = "containerd" </ins> maxPidFileLength      = 1 << 10 // 1KB )

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: docker-containerd have renamed to containerd, but EnsureDockerInContainer check not update,so it not work What you expected to happen: Is this check still needed How to reproduce it (as minimally and precisely as possible): no need 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:
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
cc
feel free to send an PR update with new name for the process and the location of the pid file.
Change:
// First time this key has been used, try creating new value. if index == 0 { <del> _, err = h.Client.Create(key, string(data), 0) </del> <ins> response, err := h.Client.Create(key, string(data), 0) </ins> if IsEtcdNodeExist(err) { continue } <ins> _, _, err = h.extractObj(response, err, ptrToType, false, false) </ins> return err }

Discussion:
The use of AtomicUpdate by genericetcd doesn't handle conflicting writes by rejecting that to a user. It should. Eventually, we may want to hide write conflicts to /pods when status has changed, and to spec when /pods/status changes, but that requires us to have two version counters and that's not worth the effort. Fix incoming.
Also we need a unit/integration test for this.
Change:
return os.bsOpts.TrustDevicePath } <ins> // NodeVolumeAttachLimit specifies number of cinder volumes that can be attached to this node. func (os *OpenStack) NodeVolumeAttachLimit() int { return os.bsOpts.NodeVolumeAttachLimit } </ins> // GetLabelsForVolume implements PVLabeler.GetLabelsForVolume func (os *OpenStack) GetLabelsForVolume(ctx context.Context, pv *v1.PersistentVolume) (map[string]string, error) { // Ignore if not Cinder.

Discussion:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Change:
rules: # Discourage import of k8s.io/kubernetes/test/e2e - selectorRegexp: k8s[.]io/kubernetes/test/e2e <del> # TODO: import-boss --include-test-files is catching these; drive to zero allowedPrefixes: # test/integration/auth/bootstraptoken_test.go is using this - k8s.io/kubernetes/test/e2e/lifecycle/bootstrap </del> <ins> forbiddenPrefixes: - "" </ins>

Discussion:
Originally tracked at . After fixing "not include test files in import-boss" in , we have a regression here: is using . We need remove dependencies from integration tests to e2e tests again. /assign /sig testing
/sig auth as per the required change
/kind cleanup /area test
It would be helpful to outline an argument as to why this is the case. I can imagine reasons, but none are mentioned here.
Description updated.
/triage accepted /priority backlog /milestone v1.21 This seems a simple enough fix to land (and thank you for doing this) but marking low enough priority to make it clear we may back out and wait for v1.22 if we don't have bandwidth for this
So while I think we should probably do this anyhow I want to note: This issue lists the reasons: we have no intention to stage e2e (there's been much discussion about this since then) we generally don't want anything non-informational (required jobs) running only sometimes anyhow, it's just not reliable Decoupling these seems like a good idea from a purely code-organization perspective, but the reasons in the previous issue are no longer valid.
/milestone v1.22 The PR didn't land in time. At this point I view this as nice to have. Even if it's low impact, let's wait until next release.
Change:
"time" "github.com/onsi/ginkgo/v2" <ins> "sigs.k8s.io/yaml" </ins> openapiutil "k8s.io/kube-openapi/pkg/util" "k8s.io/utils/pointer" <del> "sigs.k8s.io/yaml" </del> "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions" apiextensionsv1 "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"

Discussion:
<img width="1480" alt="image" src="" /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig api-machinery
cc in case you know of something that just merged
Last good run : First bad run : k8s version stamp: GOOD: "v1.30.0-alpha.3.56+" BAD : "v1.30.0-alpha.3.62+" Here's the comparison of what went in: We have a winner :) - Will leave this to !
/assign
Thanks I've opened and kicked off the alpha tests on that PR to ensure the fix sticks.
These tests appear to be passing in latest runs: (although NPD is failing)
yea, for the NPD failure i had a cherry pick to containerd 1.7 here -
/triage accepted
Change:
return nil } <ins> func (*fakeFramework) RejectWaitingPod(uid types.UID) { } </ins> func (*fakeFramework) ClientSet() clientset.Interface { return nil }

Discussion:
What would you like to be : When the pod is scheduled to the phase and I delete the pod, the pod still remains in the until the plugin allow/reject/timeout(Especially when waiting for a long time). Why is this needed: We need to take the initiative to delete the data in the and terminate the process in waiting state of plugin to ensure data accuracy, if the pod has been deleted /cc /priority important-soon /assign /sig scheduling
I think we can update the event handler for deleting pods to reject the pod. Can you send a PR for that?
OKI will send a pr for it.
Change:
"doc.go", "longrunning.go", "maxinflight.go", <del> "panics.go", </del> "timeout.go", <ins> "wrap.go", </ins> ], tags = ["automanaged"], deps = [

Discussion:
This is simple cleanup. It is unnecessarily disconcerting to read through apiserver logs and find every log line is from the file "". We should adjust the code printing these lines, either by changing the file name, or (ideally) by making it more intelligent about logging the source of the call (e.g., callers--).
, i'd like to try this one :).
No activity on this one, will try to fix it.
Has it been resolved? Can I try?
check out for discussion about it.
Change:
}, numErrs: 1, }, <ins> { name: "LoadBalancer type cannot have None ClusterIP", tweakSvc: func(oldSvc, newSvc *api.Service) { newSvc.Spec.ClusterIP = "None" newSvc.Spec.Type = api.ServiceTypeLoadBalancer }, numErrs: 1, }, </ins> } for _, tc := range testCases {

Discussion:
Create the following svc: It should fail.
I will try to take a shot at it.
Awesome! Make sure to handle updates in all directions. Historically it is the thing we forget. , Maciej Kwiek wrote:
do you have any examples of this behaviour breaking something? It would help with justifying my PR in code review process :). I know it makes sense to fix this issue, but an example would be nice.
I had a user report thatthey didn't know what was happening - the API should have rejected it with a message that you can't have headless services with load balancers. , Maciej Kwiek wrote:
please what are really use cases where we can use k8s headless service, DB, Proxies .. ?
Change:
ARCH?=amd64 HYPERKUBE_BIN?=_output/dockerized/bin/linux/$(ARCH)/hyperkube <del> BASEIMAGE=gcr.io/google-containers/debian-hyperkube-base-$(ARCH):0.3 </del> <ins> BASEIMAGE=gcr.io/google-containers/debian-hyperkube-base-$(ARCH):0.4 </ins> TEMP_DIR:=$(shell mktemp -d -t hyperkubeXXXXXX) all: build

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: When I update the kubelet on a node from 1.7.x to 1.8.0, pods on that node stop being able to connect to services whose pods happen to be on the same node. I use the Kubenet network plugin. What you expected to happen: Pods should be able to connect to a service even if the services's pods are on the same node. How to reproduce it (as minimally and precisely as possible): a cluster the DNS addon another pod that runs on the same node as one of the DNS pods resolution starts to fail when the service redirects the requests to the pod that is on the same node. Anything else we need to know?: I have some packet captures that I can show. Kubelet: 1.7.5 DNS pod: 10.2.4.76 Origin pod: 10.2.4.64 Kubelet: 1.8.0 DNS pod: 10.2.1.254 Origin pod: 10.2.1.234 We can see that in the requests that fail the DNS IP is correctly DNATed to the DNS POD destination address but the response is not masqueraded, it still carries the DNS POD source (it should have an origin of 10.3.0.10). Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Azure StandardA4 OS (e.g. from /etc/os-release): "Container Linux by CoreOS 1465.8.0 (Ladybug)" Kernel (e.g. ): Linux node-1-vm 4.12.14-coreos SMP Wed Sep 20 22:20:05 UTC 2017 x8664 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools:
/sig node
The problem appears when transitioning from kubelet v1.8.0-alpha.2 to v1.8.0-alpha.3.
Well, I've found the problem. Starting from v1.8.0-alpha.3 the "modprobe" binary is not included in the image and so the br-netfilter kernel module is not loaded. I'm using the image, although through "kubelet-wrapper" from CoreOS. Where should this binary reside?

cc/ 1.8 release team.
There is a PR from so it doesn't get lost.
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
for _, ip := range sourceRanges { sourceAddressPrefixes = append(sourceAddressPrefixes, ip.String()) } <ins> for _, serviceTag := range serviceTags { sourceAddressPrefixes = append(sourceAddressPrefixes, serviceTag) } </ins> } expectedSecurityRules := []network.SecurityRule{}

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When using the loadBalancerSourceRanges property of a service in a manifest, we are force to use a CIDR block. This was discovered while debugging the following issue. What you expected to happen: Azure allows us to use Service Tags (e.g. VirtualNetwork, Internet, etc) WE should be able to specify them form a k8s service manifest. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.11 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): centOS 7.3 Kernel (e.g. ): 3.10 Install tools: Others:
/sig azure
Here's the requested Feature.
SourceRanges is part of service spec, while serviceTag is azure specific. I think we don't expect to add cloud-specific features into Kubernetes API. What about adding a new annotation for this? e.g.
I believe that at this stage, (no out of tree cloud provider logic), using an annotation would be the only way to go unfortunately.
/priority important-soon
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : New functionality. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
} func (l *latencyAdapter) Observe(ctx context.Context, verb string, u url.URL, latency time.Duration) { <del> l.m.WithContext(ctx).WithLabelValues(verb, u.String()).Observe(latency.Seconds()) </del> <ins> l.m.WithContext(ctx).WithLabelValues(verb, u.Host).Observe(latency.Seconds()) </ins> } type resultAdapter struct {

Discussion:
Issue originating from: The label seems to be unused, but it can cause issues with high cardinality. On k3s this label has unbound cardinality due to the inclusion of url param like timeout. Examples from my small k3s cluster: ! query returns: Metrics at fault here seems to be: I didn't expect these metrics to generate this many series. Execute the following promQL query or its equivalent for your monitoring platform scraping kubelet: We could mitigate this issue by pruning the query parameter from the label. I am no kubelet expert so I don't know if it is normal that the timeout query parameter is variable, but if not that might be an issue as well. v1.22.3 <detailsNone </details<details</details<details</details<details</details<details</details
/sig instrumentation /sig node /cc
/triage accepted What timeseries is this coming from?
Updated the issue. It should be:
Since these metrics are coming from component-base, I guess we could remove sig-node, wdyt /assign
These metrics appear to have existed for 2 years, suggesting that this bug has been present for many, many releases... is this k3s specific? Edit: rate_limiter metrics weren't registered before 1.22:
/assign FYI
I think these metrics are broken for all components, not just kubelet, so I'd prefer that we try to fix the cardinality issue rather than just deregister from kubelet. I'd suggest we fix them by paring down the URL to something that's actually aggregatable, e.g. becomes That also looks a little like an URL quoting issue, I'd expect the particular namespace is substituted in... Not a release blocker since this has been present since 1.22. /priority important-soon
/remove-sig node
Maybe I misunderstood your point but IIUC the actual namespace value is replaced by the generic value to avoid excessive cardinality.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
were you able to find a work around. We just had the same issue occurred for us on multiple clusters. It brought down Prometheus :(
Change:
SubPathExpr: "$(POD_NAME)", }, { <del> Name:      "workdir2", </del> <ins> Name:      "workdir1", </ins> MountPath: "/volume_mount", }, },

Discussion:
/kind cleanup /sig storage /sig node /sig testing Description: Change e2e tests to use EmptyDir instead of HostPath as pre-requisite to promoting VolumeSubpathEnvExpansion to Conformance. Related Issues: Conformance Tests:
/cc
/assign
Change:
} func (rc *resourceMetricsCollector) collectContainerMemoryMetrics(ch chan<- metrics.Metric, pod summary.PodStats, s summary.ContainerStats) { <del> if s.Memory == nil { </del> <ins> if s.Memory == nil || s.Memory.WorkingSetBytes == nil { </ins> return }

Discussion:
kubelet panic when accessing metrics/resource endpoint kubelet log kubelet works fine access metrics/resource endpoint of kubelet No response <details</details<details</details<details</details<details</details<detailsINFO[2022-07-14 05:36:21.474173892Z] Starting CRI-O, version: 1.23.0, git: (dirty) Version: 1.23.0 GitCommit: GitTreeState: dirty BuildDate: 1980-01-01T00:00:00Z GoVersion: go1.17.4 Compiler: gc Platform: linux/amd64 Linkmode: static BuildTags: apparmor, excludegraphdriverdevicemapper, seccomp, selinux SeccompEnabled: true AppArmorEnabled: true </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
/assign
/sig node
Change:
klog.Warningf("secret %q not found in namespace %q", secretCredentialManager.SecretName, secretCredentialManager.SecretNamespace) } <ins> // Converting server FQIN to lowercase to consolidate with config parsing approach server = strings.ToLower(server) </ins> credential, found := secretCredentialManager.Cache.GetCredential(server) if !found { klog.Errorf("credentials not found for server %q", server)

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: kube-controller-manager is unable to locate the credentials of the vCenter host, even though they are defined and cased identically to the hostname in the cloud-provider-config. What you expected to happen: vCenter hostname should not be case-sensitive, or should be documented that it is. It should successfully locate credentials from the manager How to reproduce it (as minimally and precisely as possible): to an upper-case name kube-controller-manager daemon to update the secret to provision storage with the "thin" storage class will stay suck in pending Anything else we need to know?: Log Messages: ` This appears to be induced by the way the vCenter server name is calculated when the secret containing the credentials is parsed[]. The credentialKey is converted to lower case and is then parsed to lookup the server name. Environment: Kubernetes version (use ): v1.14 Cloud provider or hardware configuration: vSphere OS (e.g: ): Unknown Kernel (e.g. ): Unknown Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area/provider/vmware
/area provider/vmware