jiebi/CodeConvo huggingface dataset:
Change:
Status: api.ConditionFalse, }, }, <ins> { name: "matching pdbs with no disruptions allowed, pod running, pod healthy, empty selector, pod not deleted by honoring the PDB", pdbs: []runtime.Object{&policyv1.PodDisruptionBudget{ ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: "default"}, Spec:       policyv1.PodDisruptionBudgetSpec{Selector: &metav1.LabelSelector{}}, Status: policyv1.PodDisruptionBudgetStatus{ DisruptionsAllowed: 0, CurrentHealthy:     3, DesiredHealthy:     3, }, }}, eviction:            &policy.Eviction{ObjectMeta: metav1.ObjectMeta{Name: "t11", Namespace: "default"}, DeleteOptions: metav1.NewDeleteOptions(0)}, expectError:         "Cannot evict pod as it would violate the pod's disruption budget.: TooManyRequests: The disruption budget foo needs 3 healthy pods and has 3 currently", podName:             "t11", expectedDeleteCount: 0, podTerminating:      false, podPhase:            api.PodRunning, prc: &api.PodCondition{ Type:   api.PodReady, Status: api.ConditionTrue, }, }, </ins> } for _, unhealthyPodEvictionPolicy := range []*policyv1.UnhealthyPodEvictionPolicyType{unhealthyPolicyPtr(policyv1.AlwaysAllow), nil, unhealthyPolicyPtr(policyv1.IfHealthyBudget)} {

Discussion:
with an empty selector selects all the pods as expected. But, during the /, the pdb is not being honored correctly i.e. all the pods are getting evicted. This issue is only observed with the empty selector and works as expected if a valid label selector is provided that selects all the pods in a namespace. When an empty selector is provided in the 's spec, the created needs to be honored by not evicting all the pods during the api call Create a simple busybox deployment with 3 replicas on a local cluster (or any cluster)Create a pdb object with an selectorCheck the status of the created pdb object that has the observed to be 3 (which is expected)Call the api to see the pdb not being honored and all the pods being evictedDelete the above pdb object and create a new one with the label selectorObserve the expected status of the pdb object same as the old one with the set to 3Call the api to observe the pdb being honored as expected No response <details</details<detailslocal cluster - N/A </details<details</details<details</details<detailsCRI-O </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 apps
/assign
Change:
"strings" "time" <ins> "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <del> "k8s.io/api/core/v1" </del> "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/util/intstr"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: dns test failure when using kube-dns with dnsmasq 2.79 dnsmasq 2.79 introduced a change to respond to all norecurse queries with ServFail. This is to prevent cache snooping where an adversary can figure out if a particular hostname has been looked up or not. We need to change the test to drop that flag, likely the intention was to not send the query upstream(outside of kubedns), but the flag will restrict the query to just dnsmasq. One instance of the test failure: https://k8s- What you expected to happen: The test should be fixed to drop the no recursion flag. How to reproduce it (as minimally and precisely as possible): Run kube-dns with dnsmasq 2.79. dig +norecurse <any hostnameAnything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig networking
/sig network
/sig network
Change:
for i := 0; i < active; i++ { go func(ix int) { defer wait.Done() <del> if err := jm.podControl.DeletePod(job.Namespace, activePods[ix].Name); err != nil { </del> <ins> if err := jm.podControl.DeletePod(job.Namespace, activePods[ix].Name, &job); err != nil { </ins> defer util.HandleError(err) } }(i)

Discussion:
Currently RC emits an event when it's creating a pod: But nothing is emitted when a pod is deleted. We should create event for scaling both ways. cc
Change:
if containerChanges.StartInfraContainer && (len(containerChanges.ContainersToStart) > 0) { glog.V(4).Infof("Creating pod infra container for %q", podFullName) podInfraContainerID, err = dm.createPodInfraContainer(pod) <ins> if err != nil { glog.Errorf("Failed to create pod infra container: %v; Skipping pod %q", err, podFullName) return err } </ins> // Call the networking plugin <del> if err == nil { err = dm.networkPlugin.SetUpPod(pod.Namespace, pod.Name, podInfraContainerID) } </del> <ins> err = dm.networkPlugin.SetUpPod(pod.Namespace, pod.Name, podInfraContainerID) </ins> if err != nil { glog.Errorf("Failed to create pod infra container: %v; Skipping pod %q", err, podFullName) <ins> // Delete infra container if delErr := dm.KillContainerInPod(kubecontainer.ContainerID{ ID:   string(podInfraContainerID), Type: "docker"}, nil, pod); delErr != nil { glog.Warningf("Clear infra container failed for pod %q: %v", podFullName, delErr) } </ins> return err }

Discussion:
I'm seeing a bug where the network plugin fails to configure networking, and yet the containers for this pod are still deployed (without networking configured). It looks like the following is occurring: 1) Kubelet attempts to create infra container in 2) Network plugin fails, returns error code. 3) Kubelet detects error and skips pod creation but does not tear down the infra container 4) On the next call, the kubelet detects that the infra container is running and deploys the other containers in the pod. The fix here is for the kubelet to clean up the infra container in when it receives the error from the network plugin and before it returns. Here are some logs illustrating the steps I described above:
Cleaning up infra container on network plugin error sounds reasonable/
Change:
package get import ( <ins> "encoding/json" </ins> "reflect" "strings" "testing"

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!--What happened: seems to have regressed in v1.13.0 and no longer sorts by creation timestamp. What you expected to happen: should sort by creation timestamp. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: N/A Environment: Kubernetes version (use ): <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
/assign
bisected to () /assign
opened to fix
/assign
Change:
local i for i in $(seq 1 "${times}"); do local out <del> # shellcheck disable=SC2086 # Disabling because "${extra_args}" needs to allow for expansion here if out=$(curl --max-time "${maxtime}" -gkfs $extra_args "${url}" 2>/dev/null); then </del> <ins> if out=$(curl --max-time "${maxtime}" -gkfs "${@:6}" "${url}" 2>/dev/null); then </ins> kube::log::status "On try ${i}, ${prefix}: ${out}" return 0 fi

Discussion:
What happened: After running ./hack/update-openapi- with the latest code, api/openapi- file became empty even when no changes were made in the code. What you expected to happen: After running ./hack/update-openapi- with the latest code, api/openapi- file should not be changed when no changes were made in the code. When I tried the same thing a few week back, I didn't encounter this problem. How to reproduce it (as minimally and precisely as possible): Download the latest kubernetes/kubernetes code and run the following script to update openapi spec. api/openapi- became empty after this. Anything else we need to know?: There's a line in update-openapi- that runs a curl command . This line was changed a few days ago by this commit: PR: I checked out the commit before and ran /update-openapi- It works. is not empty any more. Is there any new setting required before running ./hack/update-openapi- now? 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:
/sig api-machinery
cc
Hi, thanks for the report, but it is a bit weird that I could not reproduce locally: and besides, completes successfully on my machine. Could you reproduce?
Someone else also ran into this same problem and asked a question on sig-api-machinery slack yesterday. So I'm not the only one who ran into this.
could you change the args passed to curl in to and rerun the script to see if there is any error?
since it is already late here(UTC+8), I would check this issue again tomorrow
I was the "someone else" who ran into this problem :) I changed the script to use The result: Actually, it was 403 without the "S", too, but that is visible only if curl is executed in verbose mode.
Hi, thanks for your information. Given that the apiserver returned 403, I suspect the flag passed to curl has no effect in your environment, would you mind posting the output of ? I am using curl 7.64.1: In addition, I think you could try changing the curl command in to the following: and see if the problem is solved.

I tried the following and it worked for me. is no longer empty. curl version:
Thanks for your confirmation, and I have filed to address this issue.
I can confirm, it works with the changed curl command.
/triage accepted
Change:
metav1.AddToGroupVersion(scheme, metav1.SchemeGroupVersion) utilruntime.Must(example.AddToScheme(scheme)) utilruntime.Must(examplev1.AddToScheme(scheme)) <ins> utilruntime.Must(example2v1.AddToScheme(scheme)) </ins> } func newTestCacher(s storage.Interface) (*Cacher, storage.Versioner, error) {

Discussion:
The test is flaking: /assign /sig api-machinery /priority important-soon
Ok - it's fairly easy to reproduce by just adding into the test I will validate the fix.
/triage accepted
Change:
return num } <del> func countEndpointsSlicesNum(epList *discoveryv1.EndpointSliceList) int { </del> <ins> // isIPv6Endpoint returns true if the Endpoint uses IPv6 addresses func isIPv6Endpoint(e *v1.Endpoints) bool { for _, sub := range e.Subsets { for _, addr := range sub.Addresses { if len(addr.IP) == 0 { continue } // Endpoints are single family, so it is enough to check only one address return netutils.IsIPv6String(sub.Addresses[0].IP) } } // default to IPv4 an Endpoint without IP addresses return false } func countEndpointsSlicesNum(epList *discoveryv1.EndpointSliceList, addressType discoveryv1.AddressType) int { </ins> // EndpointSlices can contain the same address on multiple Slices addresses := sets.Set[string]{} for _, epSlice := range epList.Items { <ins> if epSlice.AddressType != addressType { continue } </ins> for _, ep := range epSlice.Endpoints { if len(ep.Addresses) > 0 { addresses.Insert(ep.Addresses[0])

Discussion:
All the dual stack jobs ! ,%20ipvs,%20dual,%20master All dual stacks tests Since I modified this helper function to fix a flake ,%20ipvs,%20dual,%20master The function must consider only one IP family to verify the number of endpoints /assign /sig network /sig testing
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
Change:
default: errString := "you must specify two arguments: verb resource or verb resource/resourceName." usageString := "See 'kubectl auth can-i -h' for help and examples." <del> return errors.New(fmt.Sprintf("%sn%s", errString, usageString)) </del> <ins> return fmt.Errorf("%sn%s", errString, usageString) </ins> } }

Discussion:
What happened: If you use to test whether a user can approve certificate signing requests, you get a response indicating that is not a valid verb An example of the verb being used can be seen What you expected to happen: should be recognized as a valid verb on objects. How to reproduce it (as minimally and precisely as possible): Run Anything else we need to know?: I think that needs to be to the kubectl auth can-i code Environment: Kubernetes client and server versions (use ): Cloud provider or hardware configuration: OS (e.g: ):
This issue is currently awaiting triage. SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the label. 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
I don't think is a valid verb for kubectl auth command. Valid verbs are in
so in that line of code there are a number of verbs which are only usuable on specific objects for example which works on users. AFAIK the point of that line is to inform kubectl what the valid verbs are on any object in Kubernetes, so that it knows what's possible when users use the command. the verb is valid on certificate objects as shown in the docs example I listed. Without being present in that line of code, will incorrectly state that there is no verb in Kubernetes.
I tested it, seems working when we add in that list. But the question is should we add it or not?
There have been cases where Kubectl has had additions to handle non-standard resources/verbs in the past (e.g. I raised a couple of years back). AFAIK the explicit list of verbs here is designed to address this point, it's just not got approve in it. You could ask SIG-Auth about it, I'm sure they'd have more info.
/transfer kubenertes /sig auth Decision can be made by sig-auth
Something went wrong or the destination repo kubernetes/kubenertes does not exist. <detailsIn response to : /transfer kubenertes /sig auth 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
/transfer kubernetes/kubernetes
Something went wrong or the destination repo kubernetes/kubernetes/kubernetes does not exist. <detailsIn response to : /transfer kubernetes/kubernetes 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
/transfer kubernetes
/triage accepted
This will work even without adding verb there, adding verb just removes the warning. Submitted a PR to add that. /assign
Change:
return } proxier.network = *updatedNetwork <del> var providerAddress string for _, rs := range proxier.network.remoteSubnets { _, ipNet, err := net.ParseCIDR(rs.destinationPrefix) if err != nil { klog.Fatalf("%v", err) } if ipNet.Contains(net.ParseIP(ep.ip)) { providerAddress = rs.providerAddress } if ep.ip == rs.providerAddress { providerAddress = rs.providerAddress containsNodeIP = true } } </del> <ins> providerAddress := proxier.network.findRemoteSubnetProviderAddress(ep.ip) </ins> if len(providerAddress) == 0 { klog.Infof("Could not find provider address for %s. Assuming it is a public IP", ep.ip) providerAddress = proxier.nodeIP.String() <del> containsPublicIP = true </del> } hnsEndpoint := &endpointsInfo{

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: In Overlay mode, When 2 service has the same backend node IP, the LB was not programmed correctly causing datapath issues. What you expected to happen: Service data path to work properly How to reproduce it (as minimally and precisely as possible): 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:
/sig network /sig windows These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
------ TODO: Document events (refer to another doc for details) <ins> API Documentation ----------------- API documentation can be found at [http://kubernetes.io/third_party/swagger-ui/](http://kubernetes.io/third_party/swagger-ui/). </ins>

Discussion:
The schema understood by the Kubernetes configuration file is not described any where. The current practice mostly is copy/paste existing samples (for example ) and edit them. There is a need to define a comprehensive list of elements, and their documentation, so that other examples can leverage them.
Configuration files specify exactly our API objects. See:
This is exactly what I was looking for but not easily googlable, or documented clearly.
Could you please put a link to the swagger UI here?
The only mention in the public docs is here: which links directly to the struct definition on github. It appears that the Swagger docs have been deprecated, and I'm unable to find any documentation for the KubeletConfiguration resource kind in the new docs. It's referred to in at least one place, but is still not actually covered:
Change:
glog.Errorf("computeHostTags exceeded maxPages=%d for Instances.List: truncating.", maxPages) } } if len(tags) == 0 { <del> glog.V(2).Info("No instances had tags, creating rule without target tags") </del> <ins> return nil, fmt.Errorf("No instances found") </ins> } return tags.List(), nil }

Discussion:
In some custom setup cases the prefix-matching logic for GCE load-balancers can break and end up creating a firewall rule with no tags. We should instead refuse to create the rule. In fact, if we find it, we should probably delete the rule, but that's maybe too aggressive. Looking at the logic, if we return error in the tag-selection, we'll abort the whole load-balancer creation, which is unfortunate, but not TERRIBLE. We could just silently not create the firewall but not return error, which will just retry over and over.
/cc
Are you active on this? may have some starter-project bandwidth to help.
Not active. It would indeed be a good starter project :)
Change:
// if this is a pod in an older version AND there is a new version of this pod, record when // we started seeing this, otherwise delete the record (perhaps the node was drained) if nodesToVersions[pod.Spec.NodeName][newVersion] > 0 { <del> if _, ok := ageOfOldPod[string(pod.UID)]; !ok { ageOfOldPod[string(pod.UID)] = now </del> <ins> if _, ok := nodeToAgeOfOldPod[pod.Spec.NodeName][string(pod.UID)]; !ok { if _, ok := nodeToAgeOfOldPod[pod.Spec.NodeName]; !ok { nodeToAgeOfOldPod[pod.Spec.NodeName] = make(map[string]time.Time) } nodeToAgeOfOldPod[pod.Spec.NodeName][string(pod.UID)] = now </ins> } } else { <del> delete(ageOfOldPod, string(pod.UID)) </del> <ins> delete(nodeToAgeOfOldPod, pod.Spec.NodeName) </ins> } } // purge the old pods list of any deleted pods <del> for uid := range ageOfOldPod { if !podUIDs.Has(uid) { delete(ageOfOldPod, uid) </del> <ins> for node, uidToTime := range nodeToAgeOfOldPod { for uid := range uidToTime { if !podUIDs.Has(uid) { delete(uidToTime, uid) } } if len(uidToTime) == 0 { delete(nodeToAgeOfOldPod, node) </ins> } } deliberatelyDeletedPods = deliberatelyDeletedPods.Intersection(deletedPodUIDs)

Discussion:
/kind flake /sig apps This is an old flaking since , but the flaky rate is not that high. The rate in recent runs in is about 3/23 ~ 13%.
/priority backlog as the failure rate now is not high /cc old threads in and
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority backlog as the failure rate now is not high /cc old threads in and 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
/priority backlog
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten still flaking
/triage accepted /assign
Change:
Key:    key, Values: exp.Values, } <del> } else if exp.Key == key { newExp = exp </del> } else { <del> return nil, fmt.Errorf("unknown topology key: %v", exp.Key) </del> <ins> // Other topologies are passed through unchanged. newExp = exp </ins> } newTerm.MatchLabelExpressions = append(newTerm.MatchLabelExpressions, newExp) }

Discussion:
Unknown allowedTopology labels cause csi translation to fail: However, on GKE other labels are sometimes used in PV node affinity, such as or It's not common (100s of clusters as of July 2021), but seems enough that it should be dealt with. The suggestion is to just pass unknown topologies through. If they are used in the storageclass labels they will cause failures, but that is the current gce-pd behavior anyway. This reasoning probably holds for other clouds as well, although I haven't tested it myself. /assign /sig storage
/triage accepted
Change:
break } if !found { <del> glog.Fatalf("Unable to find suitible network address in list: %v", addrs) </del> <ins> glog.Errorf("Unable to find suitible network address in list: '%v'n"+ "Will try again in 5 seconds. Set the public address directly to avoid this wait.", addrs) time.Sleep(5 * time.Second) </ins> } } }

Discussion:
I'm not using publicaddressoverride. At boot I'm trying to launch using: /usr/bin/kube-apiserver --logtostderr=true --v=0 --etcdservers=http://10.13.137.165:4001 --address=0.0.0.0 --port=8080 --kubeletport= --allowprivileged=true --portalnet=10.254.0.0/16 But this gets launched before eth0 has an ip address. This used to work. Now apiserver just refused to start (complaining about 127.0.0.1 being invalid). I think it needs to just keep trying until it gets an address and can get to work....
Adding --publicaddressoverride= as suggested doesn't help.... Nov 05 12:43:55 localhost kube-apiserver[713]: F1105 12:43:55. ] listen tcp 10.13.137.165:7080: bind: cannot assign requested address Which is a fatal error. I can't bind to it. It isn't up yet.
Bisect says either commit or
If publicaddressoverride is specified, I can put the read-only server bind in a goroutine and retry periodically. If it's not, though, since we can't change the public address once started, we'd have to delay construction until a suitable address shows up. That's pretty ugly; is it an important case to support?
I personally think delaying construction is fine. Being able to launch the apiserver on any node from the init system and have it just work 99% of the time seems like a good thing....
OK. Fix coming in 3, 2, 1...
See if does the trick for you.
commented there. it fixed it.