jiebi/CodeConvo huggingface dataset:
Code change:
nodeIP:            netutils.ParseIPSloppy("::"), nodeAddresses:     []v1.NodeAddress{}, cloudProviderType: cloudProviderExternal, <del> expectedAddresses: []v1.NodeAddress{}, shouldError:       false, </del> <ins> expectedAddresses: []v1.NodeAddress{ {Type: v1.NodeHostName, Address: testKubeletHostname}, }, shouldError: false, </ins> }, { name:              "cloud provider is external and no nodeIP", nodeAddresses:     []v1.NodeAddress{}, cloudProviderType: cloudProviderExternal, <del> expectedAddresses: []v1.NodeAddress{}, shouldError:       false, </del> <ins> expectedAddresses: []v1.NodeAddress{ {Type: v1.NodeHostName, Address: testKubeletHostname}, }, shouldError: false, </ins> }, { name: "cloud doesn't report hostname, no override, detected hostname mismatch",

Related discussion:
text: It looks like there was a change that first appeared in Kubernetes 1.29, where in 1.29 the flag on kubelet is no longer being used to populate the Node's Addresses.Hostname value. Here is the relevant output from a for a 1.28 cluster with : And here's the output from a 1.29 cluster with the same configuration: Here is the full list of parameters in case that is helpful: This is from an IBM Cloud Kubernetes Service 1.28 and 1.29 cluster. We do not think there was any cloud-configuration-manager or any other related change that would cause this difference. Is it possible it is a side effect of ? I expected the behavior to be consistent between Kubernetes releases, since I didn't find any reference to this change in Create an IBM Cloud Kubernetes Service cluster at 1.28 and 1.29 and see the difference No response <details</details<details</details<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
yeah, it seems likely my change broke this, it should keep working as you say, let me take a look /assign
/sig network /sig cloud-provider
/assign /unassign Thanks
FYI it was an unintended side effect of:
Do the sig cloud provider folks need to help here? We did make external cloud providers the default as of 1.29, which may have uncovered this. Let us know!
No, it's just a dumb kubelet startup bug. Well, not dumb, but easy to fix.
It seems the problem is that once kubelet sets the hostname the cloud controller manager does not override it so maybe the right behavior is only override it if is actually overridden ?
what problem?
Code change:
nodeIP:            netutils.ParseIPSloppy("::"), nodeAddresses:     []v1.NodeAddress{}, cloudProviderType: cloudProviderExternal, <del> expectedAddresses: []v1.NodeAddress{}, shouldError:       false, </del> <ins> expectedAddresses: []v1.NodeAddress{ {Type: v1.NodeHostName, Address: testKubeletHostname}, }, shouldError: false, </ins> }, { name:              "cloud provider is external and no nodeIP", nodeAddresses:     []v1.NodeAddress{}, cloudProviderType: cloudProviderExternal, <del> expectedAddresses: []v1.NodeAddress{}, shouldError:       false, </del> <ins> expectedAddresses: []v1.NodeAddress{ {Type: v1.NodeHostName, Address: testKubeletHostname}, }, shouldError: false, </ins> }, { name: "cloud doesn't report hostname, no override, detected hostname mismatch",

Related discussion:
text: we are discussing if the fix should be backported or not It seems you are relaying on the with type Hostname and this not clearly documented We also find out recently that the behavior of this address will be overriden if the external cloud provider configures it if the external cloud provider returns the hostname , then this problem will be solved without need to backport
(Well, to clarify my comments there: it's not well-defined between different clouds and node linux distros. If you know what cloud and distro you are on, then the behavior might be consistent and usable, but that still makes for a lousy kubernetes API.) Anyway, the question here is: was this actually breaking anything major, or did you just happen to notice this and think "that's weird"? (Also, if anyone else was broken by this bug, feel free to chime in; trying to figure out what to do about backporting this, because the original fix for this bug ended up introducing another bug, and the fix for that_ bug is maybe not backport-able...)
So far I have only heard from a single customer (who was using IBM Cloud Kubernetes Service) who had something in their cluster relying on cluster node's Address.Hostname value, and so when they updated to 1.29 they were broken. I believe they just modified their code to get this "Hostname" value (which was really the node IP) from somewhere else. So, to answer the question, it is somewhere between the "I noticed it and thought 'that's weird'" option and the "it broke something major" option. We have this documented in our 1.29 release notes for IBM Cloud Kubernetes Service, so other customers will have fair warning before updating. So at this point I don't consider fixing this in 1.29 as essential.
Code change:
} func (mounter *execMounter) IsNotMountPoint(dir string) (bool, error) { <del> return IsNotMountPoint(mounter, dir) </del> <ins> return isNotMountPoint(mounter, dir) </ins> } func (mounter *execMounter) IsLikelyNotMountPoint(file string) (bool, error) {

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!--What happened: There's , and . The former is used by local and nfs volume plugins, while the latter is used by , which is also used by local and nfs volume plugins. What you expected to happen: Can we consolidate these? This is really confusing and could easily be the source of bugs. <!-- DO NOT EDIT BELOW THIS LINE --/kind cleanup
cc
/assign I'd like to clean up code.
Code change:
<ins> // Build it with: //   $ dot -Tsvg releasing.dot >releasing.svg digraph tagged_release { size = "5,5" // Arrows go up. rankdir = BT subgraph left { // Group the left nodes together. ci012abc -> pr101 -> ci345cde -> pr102 style = invis } subgraph right { // Group the right nodes together. version_commit -> dev_commit style = invis } { // Align the version commit and the info about it. rank = same // Align them with pr101 pr101 version_commit // release_info shows the change in the commit. release_info } { // Align the dev commit and the info about it. rank = same // Align them with 345cde ci345cde dev_commit dev_info } // Join the nodes from subgraph left. pr99 -> ci012abc pr102 -> pr100 // Do the version node. pr99 -> version_commit dev_commit -> pr100 tag -> version_commit pr99 [ label = "Merge PR #99" shape = box fillcolor = "#ccccff" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; ci012abc [ label = "012abc" shape = circle fillcolor = "#ffffcc" style = "filled" fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace" ]; pr101 [ label = "Merge PR #101" shape = box fillcolor = "#ccccff" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; ci345cde [ label = "345cde" shape = circle fillcolor = "#ffffcc" style = "filled" fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace" ]; pr102 [ label = "Merge PR #102" shape = box fillcolor = "#ccccff" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; version_commit [ label = "678fed" shape = circle fillcolor = "#ccffcc" style = "filled" fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace" ]; dev_commit [ label = "456dcb" shape = circle fillcolor = "#ffffcc" style = "filled" fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace" ]; pr100 [ label = "Merge PR #100" shape = box fillcolor = "#ccccff" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; release_info [ label = "pkg/version/base.go:ngitVersion = "v0.5";" shape = none fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; dev_info [ label = "pkg/version/base.go:ngitVersion = "v0.5-dev";" shape = none fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; tag [ label = "$ git tag -a v0.5" fillcolor = "#ffcccc" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; } </ins>

Related discussion:
text: Right now, we have a mixture of user documentation and developer documentation in the top-level directory. We should make it easier to find a just user documentation. Step 1 would be to move developer documentation into a subdir like docs/development or something like that. User docs would stay in the top-level docs dir.
move to
Code change:
loadBalancerName := cloudprovider.GetLoadBalancerName(apiService) serviceName := types.NamespacedName{Namespace: apiService.Namespace, Name: apiService.Name} <del> securityGroupIDs, err := c.buildELBSecurityGroupList(serviceName, loadBalancerName, annotations[ServiceAnnotationLoadBalancerExtraSecurityGroups]) </del> <ins> securityGroupIDs, err := c.buildELBSecurityGroupList(serviceName, loadBalancerName, annotations) </ins> if err != nil { return nil, err }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature /sig aws What happened: In k8s 1.7, when creating a service of type LoadBalancer, K8S creates the ELB and a Security Group for it. For these resources, it adds a tag, constructed dynamically, containing the cluster id: "${cluster_id}" with the value "true" What you expected to happen: We'd like to have also a statically named tag , as it was in 1.5 ("KubernetesCluster") with the value of the cluster id. How to reproduce it (as minimally and precisely as possible): Running on AWS cloud provider, create a service of type LoadBalancer. Anything else we need to know?: The reason for what we expect is that we have tight security constraints that require us to fine tune the IAM policies for the Instance profiles that the controllers use. With a statically named tag we were able, in 1.5, to restrict the permissions in the IAM policy to act only on the k8s managed resources (ELBs, security groups). Here is the relevant part of the IAM policy: With a dynamically named tag we are not able to do this any more as AWS IAM doesn't support something like: We are sharing the Instance Profiles among different k8s clusters, hence the "" in the value of the tag. Environment: Kubernetes version (use ):Cloud provider or hardware configuration*: AWS OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: kube-aws Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : <!-- This form is for bug reports and feature requests ONLY! -- /sig aws In k8s 1.7, when creating a service of type LoadBalancer, K8S creates the ELB and a Security Group for it. For these resources, it adds a tag, constructed dynamically, containing the cluster id: "${cluster_id}" with the value "true" We'd like to have also a statically named tag , as it was in 1.5 ("KubernetesCluster") with the value of the cluster id. Running on AWS cloud provider, create a service of type LoadBalancer.
Code change:
loadBalancerName := cloudprovider.GetLoadBalancerName(apiService) serviceName := types.NamespacedName{Namespace: apiService.Namespace, Name: apiService.Name} <del> securityGroupIDs, err := c.buildELBSecurityGroupList(serviceName, loadBalancerName, annotations[ServiceAnnotationLoadBalancerExtraSecurityGroups]) </del> <ins> securityGroupIDs, err := c.buildELBSecurityGroupList(serviceName, loadBalancerName, annotations) </ins> if err != nil { return nil, err }

Related discussion:
text: The reason for what we expect is that we have tight security constraints that require us to fine tune the IAM policies for the Instance profiles that the controllers use. With a statically named tag we were able, in 1.5, to restrict the permissions in the IAM policy to act only on the k8s managed resources (ELBs, security groups). Here is the relevant part of the IAM policy: Environment: Kubernetes version (use ):OS (e.g. from /etc/os-release):Others: </details
I believe they are moving away from the tag since there are many resources that can be shared by multiple clusters. could you use an annotation?
We removed the condition in roles in the end. Thank you for your suggestion.
That annotation affects the ELB but not any security groups that are created. can you please reopen this? You reported a real issue, and even if it no longer affects you, it needs to be tracked and fixed.
Indeed, this might be a feature that someone else would need.
In fact, this is a feature I need!
Food for thought: should we propagate the tags on the ELB to the SG, or should we introduce an annotation for the SG specifically?
Code change:
kube::test::get_object_assert 'rc mock2' "{{${labels_field}.status}}" 'replaced' fi fi <ins> # Command: kubectl edit multiple resources temp_editor="${KUBE_TEMP}/tmp-editor.sh" echo -e '#!/bin/bashnsed -i "s/status: replaced/status: edited/g" $@' > "${temp_editor}" chmod +x "${temp_editor}" EDITOR="${temp_editor}" kubectl edit "${kube_flags[@]}" -f "${file}" # Post-condition: mock service (and mock2) and mock rc (and mock2) are edited if [ "$has_svc" = true ]; then kube::test::get_object_assert 'services mock' "{{${labels_field}.status}}" 'edited' if [ "$two_svcs" = true ]; then kube::test::get_object_assert 'services mock2' "{{${labels_field}.status}}" 'edited' fi fi if [ "$has_rc" = true ]; then kube::test::get_object_assert 'rc mock' "{{${labels_field}.status}}" 'edited' if [ "$two_rcs" = true ]; then kube::test::get_object_assert 'rc mock2' "{{${labels_field}.status}}" 'edited' fi fi # cleaning rm "${temp_editor}" </ins> # Command # We need to set --overwrite, because otherwise, if the first attempt to run "kubectl label" # fails on some, but not all, of the resources, retries will fail because it tries to modify

Related discussion:
text: When trying to edit multiple resources, for example: will panic. Ref as the possible cause cc
if was the cause, any fix needs to happen in 1.1 as well, was already cherry picked there
Also shows that we need a test for this case.
is the cause. When we edit multiple resources (i.e., list-type objects), the list's Accessor.annotations (type ) is nil and will panic when UpdateApplyAnnotation tries to SetAnnotations ().
Code change:
// Returns true if and only if changes were made // The security group must already exist func (c *Cloud) addSecurityGroupIngress(securityGroupID string, addPermissions []*ec2.IpPermission) (bool, error) { <ins> // We do not want to make changes to the Global defined SG if securityGroupID == c.cfg.Global.ElbSecurityGroup { return false, nil } </ins> group, err := c.findSecurityGroup(securityGroupID) if err != nil { glog.Warningf("Error retrieving security group: %q", err)

Related discussion:
text: /kind bug What happened: When setting an elbSecurityGroup in for AWS, and deploying multiple services with differing ports, then the security group rules flap in AWS, causing services to become inaccessible (only one will be correctly configured at a time). What you expected to happen: I expect that the configured elbSecurityGroup's rules will not be touched at all. It must be pre-configured to permit access. Alternatively, all ports for all services are queried and managed together. How to reproduce it (as minimally and precisely as possible): See above. Anything else we need to know?: Most people are not running large clusters which may hit the AWS limits, so they won't use this option, nor see this issue. Environment: Kubernetes version (use ): 1.7.1 Cloud provider or hardware configuration**: AWS OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): 4.10.13-1-ARCH Install tools: Custom Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig aws
This is fixed by
Code change:
// canConnect returns true if a network connection is possible to the SSHPort. func canConnect(host string) bool { <ins> if _, ok := os.LookupEnv(sshBastionEnvKey); ok { return true } </ins> hostPort := net.JoinHostPort(host, SSHPort) conn, err := net.DialTimeout("tcp", hostPort, 3*time.Second) if err != nil { <ins> e2elog.Logf("cannot dial %s: %v", hostPort, err) </ins> return false } conn.Close()

Related discussion:
text: ci-kubernetes-e2e-gce-scale-correctness Kubernetes e2e suite: [sig-node] SSH should SSH to all nodes and run commands kubetest.Test Jul 10 14:01:51 UTC+0200 Kubernetes e2e suite: [sig-node] SSH should SSH to all nodes and run commands: more . Test /sig node
/cc
/triage accepted
Uhhh, this may help here
/milestone v1.22
/sig scalability FYI
I got annoyed that I couldn't click through to see the other logs, so now you can, ref: (spyglass doesn't render build- because it's 500MB, and the limit for rendering is 100MB)
/assign SIG Scalability chairs/TLs, please find someone to address or call this a non-release-blocking failure
Assigning to current scalability oncall (): /assign
This is sig-node issue - should be addres by SIG-node folks. /sig node
is being discussed as a fix for this and I'm not sure it's correct
is it sig scalability's intent that 5k node clusters should support SSH?
The SSH test in question passes in the "default" job: So the fact that this failure is unique to a scalability job means to me that scalability needs to own at least some part of this
I did a little bit of digging and ci-kubernetes-e2e-gce-scale-correctness uses option in kubetest, which according to seems to be setting KUBESSHBASTION env. So I believe this is main difference between our scalability job and "default".
Debugging the test in and providing a fix there. The crictl host PR () is doing something different.
Code change:
"//pkg/scheduler/algorithm:go_default_library", "//pkg/scheduler/algorithm/predicates:go_default_library", "//pkg/scheduler/cache:go_default_library", <ins> "//pkg/scheduler/metrics:go_default_library", </ins> "//pkg/util/hash:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library",

Related discussion:
text: /kind feature The equivalence cache feature is planned to move to beta in 1.11, and it would be useful to have some metrics attached to it. The equivalence cache should improve scheduling throughput, so we want to be able to correlate e.g. throughput with eCache hit rate. /sig scheduling /sig instrumentation
/assign misterikkit
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
Code change:
hard[v1.ResourceQuotas] = resource.MustParse("1") hard[v1.ResourceCPU] = resource.MustParse("1") hard[v1.ResourceMemory] = resource.MustParse("500Mi") <del> hard[v1.ResourceConfigMaps] = resource.MustParse("2") </del> <ins> hard[v1.ResourceConfigMaps] = resource.MustParse("10") </ins> hard[v1.ResourceSecrets] = resource.MustParse("10") hard[v1.ResourcePersistentVolumeClaims] = resource.MustParse("10") hard[v1.ResourceRequestsStorage] = resource.MustParse("10Gi")

Related discussion:
text: I ran conformance tests on a cluster that had a controller enabled that syncs a configmap across all clusters. It failed: Appears to be due to a 2 configmap limit: These clusters should pass conformance. This is a very common pattern (even Kubernetes itself does it!). I didn't run it myself, but apparently just install Istio and run the conformance suite. See for details Kubernetes version (use ): v1.20.2
/assign
my guess is the CA configmap created by default in 1.20 exacerbated this issue. I agree the conformance test should make fewer assumptions about the cluster it is running in and should accomodate default configmaps. left a comment on the PR in flight for this. I'd like to see the change picked to 1.20 as well.
/triage accepted /priority important-soon
Code change:
- base - debian-auto-upgrades - salt-helpers <ins> {% if grains.get('cloud') == 'aws' %} - ntp {% endif %} </ins> 'roles:kubernetes-pool': - match: grain

Related discussion:
text: At least on AWS, if the clock drifts 300 seconds (which it will), then we get the rather cryptic message: This is because AWS includes the timestamp in the request. Installing ntpd would stop this drifting from happening. If the drift does happen, the likely symptom is that EC2 calls would stop working: attach/detach volumes on the minions, instance sync and routing configuration on the master. I don't believe that GCE has the same problem.
Code change:
var errBadJSONDoc = fmt.Errorf("Invalid JSON Document") var errBadJSONPatch = fmt.Errorf("Invalid JSON Patch") <ins> var errBadMergeTypes = fmt.Errorf("Mismatched JSON Documents") </ins> // MergeMergePatches merges two merge patches together, such that // applying this resulting merged merge patch to a document yields the same

Related discussion:
text: /kind bug What happened: Wrote a that returned a faulty json patch which specified an our of range index (e.G. when there is only one container). This resulted in the apiserver crashing. Stacktrace: What you expected to happen: No crash /sig-api-machinery
/sig api-machinery
This maybe a bug in . I will follow this question.
This bug had been fixed in PR: you can checkout it.
Thanks for your comment but I don't think the linked PR fixed the issue, as it got merged almost a year ago and I am running Kube 1.10.1 which does contain that patch but still panics. Just from quickly looking at the code I the linked PR I believe there are two things wrong: The check if the index is valid only happens when a negative index was given should be
Once the PR of is merged I will update kubernetes.
/kind bug
Code change:
} func getMemoryStat(f *framework.Framework, host string) (rss, workingSet float64) { <del> memCmd := "cat /sys/fs/cgroup/memory/system.slice/node-problem-detector.service/memory.usage_in_bytes && cat /sys/fs/cgroup/memory/system.slice/node-problem-detector.service/memory.stat" </del> <ins> var memCmd string isCgroupV2 := isHostRunningCgroupV2(f, host) if isCgroupV2 { memCmd = "cat /sys/fs/cgroup/system.slice/node-problem-detector.service/memory.current && cat /sys/fs/cgroup/system.slice/node-problem-detector.service/memory.stat" } else { memCmd = "cat /sys/fs/cgroup/memory/system.slice/node-problem-detector.service/memory.usage_in_bytes && cat /sys/fs/cgroup/memory/system.slice/node-problem-detector.service/memory.stat" } </ins> result, err := e2essh.SSH(memCmd, host, framework.TestContext.Provider) framework.ExpectNoError(err) framework.ExpectEqual(result.Code, 0)

Related discussion:
text: N/A [sig-node] NodeProblemDetector: N/A https://prow- Not cgroupv2 compatible when access cpu and memory data
/sig node
Hi, can i work on this ?
Sure. Thanks
/assign
/triage accepted
/priority important-soon
/cc
are you still working on this? Were you able to setup environment to repro the test failure? Let us know if you need any help. Thanks!
Sorry for the delay, I followed the wrong guide and ended up getting stuck. But now I have managed to set it up. Please give me few more days to work on it.
Thanks Feel free to reach out here or on slack if you need any help, thanks for working on this!
/retitle Make nodeproblemdetector test cgroupv2 compatible
Failing job:
Testgrid: