jiebi/CodeConvo huggingface dataset:
Change:
#   ROOT #   KUBERNETES_RELEASE_TAR function upload-resources() { <del> swift post kubernetes --read-acl '.r:*,.rlistings' </del> <ins> swift post ${SWIFT_OBJECT_STORE} --read-acl '.r:*,.rlistings' </ins> locations=( "${ROOT}/../../_output/release-tars/${KUBERNETES_RELEASE_TAR}"

Discussion:
<!-- 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?: What happened: Currently swift object store has a hard-coded name: . E.g., What you expected to happen: Make swift object store parameterizable. E.g., How to reproduce it (as minimally and precisely as possible): This defaults to the hard-coded swift object store. Anything else we need to know?: Here is the patch file to address this issue: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OpenStack OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., /sig scalability for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig openstack /sig storage /remove-sig api-machinery
cc
Quick question, if you have the diff already, why not send a PR?
I noticed the contributor documentation is extensive (b/c k8s is such a big project, this is understandable) and I wasn't sure how if I was following the rules. I can send the PR, if you would like. This is no problem. Let me know :-)
I created a PR based on the diff in your issue. Please let me know if you'd like me to abandon it so that you can have credit for the work.
Here you go:
hey can you please reopen this?
I don't think I have enough privileges to reopen. It's probably best to create a new issue and reference this one.
Ah. thanks
/assign
/reopen
Looks like the bot commands worked! ()
/close
Change:
ObjectMeta: metav1.ObjectMeta{ Name:            jobName, Annotations:     map[string]string{"cronjob.kubernetes.io/instantiate": "manual"}, <del> OwnerReferences: []metav1.OwnerReference{*metav1.NewControllerRef(cronJob, apps.SchemeGroupVersion.WithKind("CronJob"))}, </del> <ins> OwnerReferences: []metav1.OwnerReference{*metav1.NewControllerRef(cronJob, cronJob.GroupVersionKind())}, </ins> }, Spec: batchv1.JobSpec{ Template: corev1.PodTemplateSpec{

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: of Job created by using command will be . This apiVersion is wrong. What you expected to happen: Set the to How to reproduce it (as minimally and precisely as possible): CronJob manifest: <details</detailsApply CronJob and execute command Anything else we need to know?: Environment: Kubernetes version (use ):
/sig cli
This was introduced by . /assign
GitHub didn't allow me to assign the following users: odino. Note that only , 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 : This was introduced by . Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I created fix pull request:
Change:
} func TestLoadBalancer(t *testing.T) { <del> ipt := iptablestest.NewFake() ipvs := ipvstest.NewFake() ipset := ipsettest.NewFake(testIPSetVersion) fp := NewFakeProxier(ipt, ipvs, ipset, nil) </del> <ins> ipt, fp := buildFakeProxier() </ins> svcIP := "10.20.30.41" svcPort := 80 svcNodePort := 3001

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? /kind bug What happened: In ipvs proxy mode, most service functions like "nodeport/loadbalance" is realized by the association of iptables/ipset/ipvs, yet most ipvs proxier ut only verified ipvs rules, which can't ensure service is functional. What you expected to happen: Check both ipvs rules and iptables chains/rules, ipset entries in ipvsproxier ut.
/sig network /area ipvs /assign
What's the current UT coverage number?
Current is 50.2%.
So, can we achieve 70%?
Yeah, we can do that, and that's definitely necessary.
Change:
klog.V(4).Infof("Found active IP %v ", finalIP) return finalIP, nil } <ins> // In case of network setups where default routes are present, but network // interfaces use only link-local addresses (e.g. as described in RFC5549). // the global IP is assigned to the loopback interface, and we should use it loopbackIP, err := getIPFromLoopbackInterface(family, nw) if err != nil { return nil, err } if loopbackIP != nil { klog.V(4).Infof("Found active IP %v on Loopback interface", loopbackIP) return loopbackIP, nil } </ins> } } klog.V(4).Infof("No active IP found by looking at default routes")

Discussion:
What happened: When attempting to kubeadm join a control plane node or worker on a machine with global IPv4 unicast addresses on a loopback address (router to the host w/ BGP Unnumbered), the join fails with the following output: See this issue for details : Also: What you expected to happen: The correct IPv4 address should be selected from the loopback adapter, or we should be able to specify an IPv4 address to use for egress. The IPv6 addresses on the network adapters themselves are only used to establish upstream peering. IPv4 nexthops are fake 169.254.x.x addresses artificially programmed via RFC5549 into the ARP table. How to reproduce it (as minimally and precisely as possible): On a node with the following conditions: Routing to the host with FRR IPv6 link locals on physical network interfaces No IPv4 addresses on physical network interfaces Unicast IPv4 on the loopback adapter IPv4 default route present via RFC5549 Attempt to kubeadm join a node, and it will fail. Anything else we need to know?: We've been patching kubeadm with , which works as expected. There was a fix applied to allow initing control plane nodes w/ bind address 127.0.0.1 which would then select an IPv4 from the loopback, but it doesn't appear to have fixed the joining issues. Pinging and by request on kubeadm issues. Environment: Kubernetes version (use ): 1.17.12 Cloud provider or hardware configuration: baremetal OS (e.g: ): Centos 7 Kernel (e.g. ): 3.10.0-1127.19.1.el7.x86_64 Install tools: kubeadm Network plugin and version (if this is a network-related bug): Calico Others: FRR for peering with routers on physical network interfaces
/sig api-machinery
is defined but we should note the same function is used for the --bind-address of the kube-apiserver. /sig network
/assign
/triage accepted
Change:
# scope and that the Logging API has been enabled for the project # in the Google Developer Console. <del> FROM ubuntu:16.04 </del> <ins> FROM gcr.io/google_containers/ubuntu-slim:0.4 </ins> MAINTAINER Alex Robinson "arob@google.com" # Disable prompts from apt.

Discussion:
It's 400+mb and we need to pull it on every node. This leads to a lot of image pulling flake (), and also gets very expensive in some countries where bandwidth is sold at a premium. We took a stab at halving the size with: , but then realized that we were using an unsupported base image We tried to optimize to ~300Mb by building a smaller ubuntu:15 base, but that's still huge. Every other mandatory system daemon is built on busybox and so takes ~10Mb.
I can try again now that the agent supports
Newer Docker images using the spec from the official repository are based on AlpineLinux and are around ~38MB:
Change:
w.proberResultsMetricLabels = prometheus.Labels{ "probe_type":     w.probeType.String(), "container_name": w.container.Name, <ins> "container":      w.container.Name, </ins> "pod_name":       w.pod.Name, <ins> "pod":            w.pod.Name, </ins> "namespace":      w.pod.Namespace, "pod_uid":        string(w.pod.UID), }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What's happening: Currently, the metrics use the label "podname" to refer to the name of the pod in a timeseries and "containername" to refer to container names within that pod. kube-state-metrics, however, uses "pod" to refer to the names of pods and "container" to refer to names of containers. This difference makes it difficult to do joins on KSM metrics and cadvisor metrics, leading me to write queries like this one (which calculates the percentage of real utilization of quota per container -- namespace and podname templated in Grafana): With normalized labels I could just write Hence, I propose renaming the "podname" labels to "pod" and "containername" labels to "container" to normalize between the two data sources. I can attempt to write a patch for this. Why propose this here rather than telling KSM to match the cadvisor metrics? I reported this against KSM first: The indicate the usage of "container" (vs. containername), "pod" (vs. podname), etc.: Fixing this would ensure the cadvisor metrics conform with the community guidelines. Environment: Kubernetes version (use ): 1.8.7-21 with internal patches Kube-state-metrics image version: 1.2.0
/sig instrumentation
I just this to be discussed in the sig-instrumentation meeting, personally I'm all for it and we've discussed this a number of times. we should figure out the timeline for node-metrics being reworked, if that is going to take a while then I think we should make these changes.
considering that now basically has a dependent change that has to go through first, I think that's ok
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with .

Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
<del> 1.23rc2 </del>  No newline at end of file <ins> 1.22.5 </ins>  No newline at end of file

Discussion:
sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)
Change:
return err } <del> return gce.waitForZoneOp(createOp, zone) </del> <ins> err = gce.waitForZoneOp(createOp, zone) if isGCEError(err, "alreadyExists") { glog.Warningf("GCE PD %q already exists, reusing", name) return nil } return err </ins> } func (gce *GCECloud) doDeleteDisk(diskToDelete string) error {

Discussion:
From : Full log: https://k8s-
Summary of my investigation: In the log I can see that for a claim started: must have called GCE volume provisioner because GCE PD was created Right after call there must be either or in the log, see [1]. Neither of these is actually in the log. This indicates that call did not finish at all. 1: On the other hand, is kept inside a . E.g. on this line we can see it is actually there and second run of the same operation was refused: The operation must have been deleted from the map because later we can see that a new operation with the same name is admitted: Conclusion: disappeared from GoRoutineMap without finishing and logging ether success or failure. Initially, I thought that call could have panicked, but there would be panic in the log and there is none. Root cause is still unknown. It looks it happened only once.
And the reason is that controller-manager was restarted after provisioning and before saving the PV to Kubernetes (at to be precise). Naturally, newly started controller-manager had empty GoRoutineMap and tries to provision a PV again. Solution: must be interpreted not as failure but as success, Kubernetes should adopt volumes it created and forgot about them. Patch will follow shortly.
Change:
} // WarningsOnCreate returns warnings for the creation of the given object. <del> func (customResourceStrategy) WarningsOnCreate(ctx context.Context, obj runtime.Object) []string { return nil </del> <ins> func (a customResourceStrategy) WarningsOnCreate(ctx context.Context, obj runtime.Object) []string { return generateWarningsFromObj(obj, nil) } func generateWarningsFromObj(obj, old runtime.Object) []string { var allWarnings []string fldPath := field.NewPath("metadata", "finalizers") newObjAccessor, err := meta.Accessor(obj) if err != nil { return allWarnings } newAdded := sets.NewString(newObjAccessor.GetFinalizers()...) if old != nil { oldObjAccessor, err := meta.Accessor(old) if err != nil { return allWarnings } newAdded = newAdded.Difference(sets.NewString(oldObjAccessor.GetFinalizers()...)) } for _, finalizer := range newAdded.List() { allWarnings = append(allWarnings, validateKubeFinalizerName(finalizer, fldPath)...) } return allWarnings </ins> } // Canonicalize normalizes the object after validation.

Discussion:
A client is allowed to add custom finalizers to Custom Resources with a finalizer name that's not fully qualified (e.g. or ). However they're prevented from doing the same on builtin resource types, returning the following error: Invalid value: "": name is neither a standard finalizer name nor is it fully qualified Per , custom finalizer names are expected to be in format "consist of a domain name, a forward slash and the name of the finalizer" (e.g. ). Therefore, I expected the enforcement to be the same for CRs and builtin types. a custom resource on the cluster it to add the edit does not fail the same on a builtin resource (e.g. Namespace or Pod), observe it fails No response Reproducible at least starting from 1.21 and still on latest versions. <details</details<detailsN/A kind cluster </details<detailsN/A - kind cluster accessed via macOS </details<details</details<details</details<details</details
/area api /cc /sig api-machinery
/assign /triage accepted
There is no validation of finalizer in and . Please unassign me if you guys have started to work on it. /assign
it is called from here on custom resources:
lacks validation for finalizer name. I have raised a pr for this. PTAL.
Change:
"k8s.io/api/core/v1" extensions "k8s.io/api/extensions/v1beta1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/client-go/kubernetes/fake" </ins> "k8s.io/client-go/util/workqueue" "k8s.io/kubernetes/pkg/controller/deployment/util" )

Discussion:
Please see There are no unit tests currently for that method. This would be a good started PR for someone interested in helping with Kubernetes.
/sig apps
/cc
/for-new-contributors
/assign
I want this done by the end of this week so we can cherry-pick both the unit test and back to 1.7 and potentially 1.6.
if nobody else is working on it, i'll look into this.
Hey Please do so and cc me on your PR, I haven't had any time to start on it.
/priority important-soon
Change:
"strings" ) <del> func GetVMUUID() (string, error) { result, err := exec.Command("wmic", "csproduct", "get", "UUID").Output() </del> <ins> func getRawUUID() (string, error) { result, err := exec.Command("wmic", "bios", "get", "serialnumber").Output() </ins> if err != nil { <del> return "", fmt.Errorf("error retrieving vm uuid: %s", err) </del> <ins> return "", err </ins> } <del> fields := strings.Fields(string(result)) if len(fields) != 2 { </del> <ins> lines := strings.FieldsFunc(string(result), func(r rune) bool { switch r { case 'n', 'r': return true default: return false } }) if len(lines) != 2 { </ins> return "", fmt.Errorf("received unexpected value retrieving vm uuid: %q", string(result)) } <del> return fields[1], nil </del> <ins> return lines[1], nil </ins> }

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: Running the vSphere cloud provider on a windows node throws the following error: This is because the vm identifier is retrieved with the command - , which assumes that the uuid and serial are the same. On some vmware vm versions, the uuid and serial are not the same. vmware (comment), vmware (comment) What you expected to happen: Kubelet is able to find vm in vCenter from the identifier looked up on the node. or should be used instead to find the vm identifier. How to reproduce it (as minimally and precisely as possible): Issue only occurs on some vm versions, such as 13. Anything else we need to know?: On the linux side, this issue was resolved by switching from looking up the id from to . See Some discussion about this issue here - Environment: Kubernetes version (use ): 14.0-beta.1 Cloud provider or hardware configuration: Vsphere OS (e.g: ): Windows 2019 Kernel (e.g. ): Install tools: Others:
/sig windows /sig vmware
/milestone v1.14
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.14 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
/assign
Change:
eventRecorder:        options.eventRecorder, informerFactory:      options.informerFactory, metricsRecorder:      options.metricsRecorder, <del> runAllFilters:        options.runAllFilters, </del> extenders:            options.extenders, PodNominator:         options.podNominator, parallelizer:         options.parallelizer,

Discussion:
Since scheduler Policy API was total removed, we don't support any more. Remove unsupported configuration.
/sig scheduling /assign
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 /cc
/sig scheduling (trying to tell the bots to remove )
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /remove-needs sig /remove-label needs-sig 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
It's true scheduler doesn't quite use this field anymore, but I'm wondering if some other project like ClusterAutoscaler or simulator still consumes this via .
There's no place we can config this field now by configure file(before we can apply the change by policy api, but now it's removed). So it seems like unless we support this feature with CC, or this field is useless. To other projects, it's the same. When they are using legacy policy api, they can configure this field, but once they synced with the latest kubernetes, with the policy api removed, they can not configure this anymore. In this situation, we should add support in CC. I don't quite understand the relationship between k/k with k/autoscaling or others, I think they sync with k/k periodic.
As I mentioned above, it's still accessible via a framework runtime programmatically, and thus may be still useful. For example, upon a scheduling failure, a ClusterAutoscaler's implementation may choose to dryrun through all filter plugins to ensure a new provisioned node can fit the pod, instead of resolving the failure while failing at another latter filter plugin.
Oh, I haven't thought of configuration via programmatically, that saved my concern. But a little strange.
That's exactly what I meant. Given it's a public option in framework, and there is no alternative if we disabled it, it'd be good to check with potential consumers.

For now I can think of CA ( and k-sigs/scheduler-simulator ( If they can confirm it's not needed in their usecases, I'm fine with removing .
To k/autoscaler, at least these codes are still there together with the legacy policy api. , looking forward to the response.
is not used in sigs/kube-scheduler-simulator. ‍
this isn't used by cluster autoscaler, we can remove it.
Change:
"github.com/stretchr/testify/assert" ) <del> func newTestScaleSet() *scaleSet { ss := newScaleSet(getTestCloud()) </del> <ins> func newTestScaleSet(scaleSetName string, vmList []string) *scaleSet { cloud := getTestCloud() setTestVirtualMachineCloud(cloud, scaleSetName, vmList) ss := newScaleSet(cloud) </ins> return ss.(*scaleSet) } <del> func setTestVirtualMachineScaleSets(ss *scaleSet, scaleSetName string, vmList []string) { </del> <ins> func setTestVirtualMachineCloud(ss *Cloud, scaleSetName string, vmList []string) { </ins> virtualMachineScaleSetsClient := newFakeVirtualMachineScaleSetsClient() scaleSets := make(map[string]map[string]compute.VirtualMachineScaleSet) scaleSets["rg"] = map[string]compute.VirtualMachineScaleSet{

Discussion:
/kind bug What happened: https://k8s-
/sig azure
I find the root cause, and can fix it.
/kind bug
/cc
Cool, thanks