jiebi/CodeConvo huggingface dataset:
Change:
message HTTPIngressPath { // Path is matched against the path of an incoming request. Currently it can // contain characters disallowed from the conventional "path" part of a URL <del> // as defined by RFC 3986. Paths must begin with a '/'. When unspecified, // all paths from incoming requests are matched. </del> <ins> // as defined by RFC 3986. Paths must begin with a '/' and must be present // when using PathType with value "Exact" or "Prefix". </ins> // +optional optional string path = 1;

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 --When I tried to use the default path I got . No error. According to the path is not needed. "When unspecified, all paths from incoming requests are matched." Create a ingress like so: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: brew Network plugin and version (if this is a network-related bug): N/A Others:
/sig network /area ingress It seems to be a problem of ingress and I suggest creating an issue in I find a similar one which is a little different there
We use - would this be a problem with the aws repo then?
/assign
So digging a bit here, the API docs needs to be improved. By the , is required if the PathPrefix is Exact or Prefix. To solve your issue specifically, you have two ways: Add that accepts ingress without paths Add and change PathPrefix to Prefix, so this becomes a catchAll I'll open a PR to fix the comment/docs. Thanks!
Thanks! In my case because I'm using ALB controller I had to use with prefix to get it working - see
/triage accepted PR will close this ;)
Change:
"-j", "DROP", ) <ins> // disable LB access from node // for IPVS src and dst both would be lbIP for _, entry := range proxier.lbNoNodeAccessIPPortProtocolEntries { proxier.filterRules.Write( "-A", string(kubeIPVSOutFilterChain), "-s", entry.IP, "-m", "ipvs", "--vaddr", entry.IP, "--vproto", entry.Protocol, "--vport", strconv.Itoa(entry.Port), "-j", "DROP", ) } </ins> // Accept all traffic with destination of ipvs virtual service, in case other iptables rules // block the traffic, that may result in ipvs rules invalid. // Those rules must be in the end of KUBE-SERVICE chain

Discussion:
When using loadBalancerSourceRanges to allow access only from CIDRs outside the cluster segment, access from the K8s nodes (or pods with hostNetwork:true) should be rejected, but for proxy-mode=ipvs it works. /sig network /area kube-proxy /area ipvs Access from K8s nodes should be rejected in the same way as for proxy-mode=iptables Define a service with loadBalancerSourceRanges that allows access from a cidr outside the cluster, e.g. The K8s nodes have addresses on 192.168.1.0/24 and fd00::c0a8:100/120. Make sure a loadBalancerIP is assigned (in this example 10.0.0.0/32) and try to access it from a K8s node: Same for both ipv4 and ipv6. This is related to since a fix requires that the passed to the is correct. Please see v1.27.4 and master None Linux 6.4.4 None N/A N/A
wanted to work on this
Great! But please coordinate with I hope that one get accepted, and then ~the s (both families) passed to the proxiers should be usable.~ No, they are not, please see
Discussed this one in the SIG Network meeting today: we agree this is something we'd like to implement, however we weren't sure exactly how to do it with ipvs during the meeting. Whoever takes this on needs to come up with and communicate a clear plan of how it will be accomplished. /triage accepted
My comment is not feasible. For proxy-mode=ipvs the src and dst is both loadBalancerIP. So the nodeIP will not help :disappointed:
I did a small experimented with kind + metallb. I created a loadbalancer service backed by . loadBalancerIP: 172.18.255.200 podIP: 10.244.1.3 conntrack picks the src and dst both as loadBalancerIP. Tried to create an iptables rules matching source and destination with loadbalancerIP to drop packets but it didn't work. After some exploration I found and with the following rules I was able to prevent access to lbIP from k8s nodes / host network.

The solution looks hacky though, we only need this rule if source ranges are defined for the service and node ip is not covered by any of them. Will try to program this in the ipvs proxier.
Good find! :+1: I had missed the ipvs extension. I started to check nodeIP and the (flawed) option to experiment with setting a nodeIP as "src" for some routes to dodge the lbip-both-as-src-and-dst problem, and an old "vision" I have to not assign clusterIPs to at all, but have one rule to replace them all, like: It can be done, and in a cluster with 1000's of clusterIP's it would simplify
Change:
"//test/utils/image:go_default_library", "//vendor/github.com/onsi/ginkgo:go_default_library", "//vendor/github.com/onsi/gomega:go_default_library", <ins> "//vendor/k8s.io/utils/net:go_default_library", </ins> "//vendor/k8s.io/utils/pointer:go_default_library", ], )

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: sig-network-kind-ipvs,dual,master sig-network-kind-ipvs,IPv6,master Which test(s) are failing: [x] KubeProxy should set TCP CLOSE_WAIT timeout [x] Conntrack should be able to preserve UDP traffic when server pod cycles for a NodePort Service [x] KubeProxy should resorve connection reset issue (tracking in ) Since when has it been failing: Oct 28 Testgrid link: sig-network-kind-ipvs,dual,master  Reason for failure: Both appear to be failing on missing conntrack entries ex. Anything else we need to know:
/sig network /cc /assign
I'm spinning up a kind cluster with ipv6+ipvs to see if I can replicate this test locally
/triage accepted
heh, the job was not running it, it started to run when we changed the tag I meant this test and the PR where we renamed the kube-proxy test
this one has an issue already open, and I have a PR for fixing it
reached out to me on Slack and we identified as the high priority. I have tested this locally and it fails on both IPTables and IPVS kind clusters locally. I'm digging through the cluster logs now.
I' ve logging to conntrack with level v4 recently just for these problems, try to bump your kube-proxy logging to v4
seems that there are less test failures on the IPv6 jobs, let's keep watching them :eyes: However, the dual-stack jobs are legit failures, basically because on dualstack clusters, the node has 2 internal IPs, and those tests use the internal IP for asserting some operations, and the problem is that they are picking the internalIP of the wrong IP family, hence the test fails The solution should be to add the InernalIp correspoding to the cluster primary IP familty, you can obtain it with but it seems that we have to modify the function or add a new one that returns the nodes and the corresponding ips
Hey Thanks for all the help, will look into the areas of the code and try to bump the logging.
Change:
if (pattern.VolMode == v1.PersistentVolumeBlock && t.runTestBlock != nil) || (pattern.VolMode == v1.PersistentVolumeFilesystem && t.runTestFile != nil) { ginkgo.It(t.testItStmt, func() { <ins> if pattern.VolMode == v1.PersistentVolumeBlock && driver.GetDriverInfo().InTreePluginName == "kubernetes.io/local-volume" { // TODO: https://github.com/kubernetes/kubernetes/issues/74552 framework.Skipf("Local volume volume plugin does not support block volume reconstruction (#74552)") } </ins> init() defer cleanup()

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (block volmode)] disruptive[Disruptive] Should test that pv used in a pod that is force deleted while the kubelet is down cleans up when the kubelet returns. Since when has it been failing: 10/8/19 Testgrid link: https://k8s- Reason for failure: Introduced by but root cause is probably Anything else we need to know:
/assign
/milestone 1.17 /priority important-soon this is consistently failing in release-master-informing job could you please take a look?
The provided milestone is not valid for this repository. Milestones in this repository: [, , , , , , , , ] Use to clear the milestone. <detailsIn response to : /milestone 1.17 /priority important-soon 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
/milestone v1.17
Change:
import ( "fmt" <ins> "sort" </ins> "github.com/go-logr/logr" json "k8s.io/component-base/logs/json"

Discussion:
What happened: 50% of builds have a different man page content What you expected to happen: It should be possible to get bit-identical build results - might need a patch similar to - knows these things. How to reproduce it (as minimally and precisely as possible): build kubernetes1.19 openSUSE package a few times and compare results. e.g. with Anything else we need to know?: Environment: OS: openSUSE-Tumbleweed While working on for , I found that when building the kubernetes1.19 package, there was sometimes such a difference between builds:
/sig release
/sig scheduling
Change:
import ( "fmt" <ins> "sort" </ins> "sync" "time"

Discussion:
I've noticed a issue where if you have multiple replicated slave pods that don't have a HOST assigned and you reduce the number of replicas in the replicationController definition for those pods, sometimes the currently assigned (and running) pods get killed and the unassigned pod will get assigned to run in the killed pods place. The issue can be reproduced using the guestbook example provided in the repo. Steps to reproduce: (Note this is not always deterministic and may need multiple attempts) the master pod the master service the replicated slaves the Slave Controller definition to only have 1 replicas the Slave Controller with new definition The expected behavior should be that the scheduler is able to determine that unassigned pods are more viable candidates when reducing number of replicas. It seems to be more likely that since this issue is not deterministic, the ordering in which the command returns result is not always deterministically in the same order
: please can you look at this or suggested someone else? Thank you.
Unassign myself from this bug since I cannot get working on this soon. Also remove kubelet from the label since it is not kubelet issue. This is obviously a replicaController issue. cc/ Instead of destroying pod in pending state, replicaController unbound running pod from a node. Kubelet running on such node has this new desire state and kill unwanted pod to match it.
Yes, the replication controller should be smarter, taking into account Phase, Readiness, recency, ... This will be a significant problem for auto-scalers, but I expect manual scaling to be infrequent. I doubt we'll get to this soon. A PR would be welcome. Place to change is here:
Hi, I am final year Master's student of International Institute of Information Technology, Hyderabad. I am familiar with docker and containers. I have basic understanding of Go language with some hands on Docker API. This project seems interesting and a solution to this will also be a good addition to Kubernetes. So I would like to pick this as my GSoC project. I have started reading about Replication Controller and Pods and going though the code. I would appreciate if someone has any inputs for me on this. Thanks, Swapnil Patil
Change:
"k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/types" <ins> utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" watch "k8s.io/apimachinery/pkg/watch"

Discussion:
[X] Test approval issue: [X] Test PR: 29 Sept 2022 [X] Two weeks soak end date: 14 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still two remaining ReplicationControllerScale endpoints which are untested for conformance. readCoreV1NamespacedReplicationControllerScalereplaceCoreV1NamespacedReplicationControllerScale Using a number of existing e2e test practices a new has been created for two ReplicationControllerScale endpoints. The e2e logs for this test are listed below. This query shows which scale endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 2 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
// Sometimes the actual containers take a second to get started, try to get logs for 60s for time.Now().Sub(start) < (60 * time.Second) { <ins> err = nil </ins> logs, err = c.Get(). Prefix("proxy"). Resource("nodes").

Discussion:
This happened on 5/6/2015 at 07:49 am on our continuous integration system, against upstream/master head at that time (i.e. last commit ). Needs to be repro'd and debugged. Docker Containers should be able to override the image's default command and arguments Failed to create pod: Pod "client-containers--f401-11e4-9118-" is forbidden: Post http://127.0.0.1:8080/api/v1beta3/namespaces: EOF
This test is still flaky. Containers should be able to override the image's default commmand (docker entrypoint) (Failed 2 times in the last 30 runs. Stability: 93 % Containers should be able to override the image's default arguments (docker cmd) (Failed 1 times in the last 30 runs. Stability: 96 %)
I will take a look at this now
Sample log from failure:
The indicates two things 1) that the test only tried once to fetch the logs, and 2) that either the call returned an empty log or an error (which it looks like the test does not check for). See
Change:
return cmdutil.UsageError(cmd, execUsageStr) } } <ins> namespace, _, err := f.DefaultNamespace() if err != nil { return err } p.Namespace = namespace clientMapper := resource.ClientMapperFunc(f.ClientForMapping) mapper, typer := f.Object() decoder := f.Decoder(true) infos, err := resource.NewBuilder(mapper, typer, clientMapper, decoder). NamespaceParam(p.Namespace).DefaultNamespace(). ResourceNames("pods", p.PodName). SingleResourceType(). Do().Infos() if err != nil { return err } if len(infos) != 1 { return cmdutil.UsageError(cmd, execUsageStr) } p.PodName = infos[0].Name </ins> cmdParent := cmd.Parent() if cmdParent != nil {

Discussion:
I feel like I should be able to do: but I get
or we have to do something like this: sounds reasonable to me. needs more comments.
All commands that accept resources should accept resource/NAME syntax. In this case for back compat we must only accept a single argument, is familiar with this.
Exactly. ResourceNames in the resource builder is what is needed here to handle the default resource (pod in this case) and provide the ability to specify more.
Related
If nobody is working on it, I'd like to pick the issue, pls.
I don't think anyone is. , Illia Khudoshyn wrote:
So could you please assign me?
I can't assign to just anyone, unfortunately, but by responding here, anyone else who might work on it will see that you are already in progress. , Illia Khudoshyn wrote:
please go ahead, you did own this now. :)
Has this been reverted again? I cannot use “pod/podname” for v1.11:
^ Seconding the above. I'm getting the same 'may not contain /' error. Naturally it's trivial to use unix commands to filter this, but this is such a basic feature and matches the way the rest of kubectl works, so it's quite a shocking omission.
as a unix novice who's also experiencing this problem, I'd love to know your workaround
If you use selectors, you can do something like this: Otherwise you'll need to manually grep, something like this: is the syntax in bash to run the command and use its output as part of another command. You can also use backticks to achieve the same effect but that's considered bad form by many (myself included). For example: If going the grep route, take care to make sure your regex will only return one result, otherwise you'll have to pipe it to xargs or something similar.
Just ran into this on a brand new default installation. Local Mac Docker for Desktop Enabled k8 in preferences error: invalid resource name "svc/broken-gorilla-postgresql": [may not contain '/']
FWIW you can use combined with the flag, e.g.
Had the same problem. Updating kubectl resolved the issue for me.
Change:
KUBERNETES_CONFIGURE_CBR0: $(yaml-quote ${KUBERNETES_CONFIGURE_CBR0:-true}) EOF fi <del> if [[ "${ENABLE_NODE_AUTOSCALER:-}" == "true" || "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </del> <ins> if [[ "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </ins> cat >>$file <<EOF <del> ENABLE_CLUSTER_AUTOSCALER: $(yaml-quote "true") </del> <ins> ENABLE_CLUSTER_AUTOSCALER: $(yaml-quote ${ENABLE_CLUSTER_AUTOSCALER}) </ins> AUTOSCALER_MIG_CONFIG: $(yaml-quote ${AUTOSCALER_MIG_CONFIG}) EOF fi

Discussion:
In kube-up we use var while in GKE, documentation, issues etc I think we call it cluster autoscaler. We should make it consistent.
I assume this is what you were already thinking, but: I think we should change it to cluster autoscaler (everywhere). You scale the cluster by adding/removing nodes. You scale a node by adding/removing resources to/from the node, so node autoscaler isn't the right term IMO.
Change:
}); err != nil { t.Errorf("Waiting for Pod to get the finalizer removed: %v", err) } <del> if !tc.inCache && jobSynced { t.Error("Tried to sync deleted job") } </del> }) } }

Discussion:
pull-kubernetes-unit TestWatchOrphanPods/orphan May 4th Waiting for Pod to get the finalizer removed: timed out waiting for the condition No response /sig apps
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
Likely a bug in
Change:
"containers":[ { "name":"redis-master", <del> "image": "gcr.io/google_containers/redis:e2e", </del> <ins> "image": "gcr.io/k8s-testimages/redis:e2e", </ins> "ports":[ { "name":"redis-server",

Discussion:
Kubernetes version (use ): master What happened: Pulling the redis image takes a while, like 30 seconds in GCE. This might be leading to periodic timeouts in tests like . What you expected to happen: Tests shouldn't depend on large images that take a potentially long time to pull. proposed fix to reduce flakiness we can increase the replica count on this test to 2 or make the redis image we use smaller (or not use redis at all and just use a simpler smaller image)
cc (considering this as a bug since we shouldnt need a 500MG image just to test kubectl :))
This should be as simple as changing the current to use alpine and install redis, instead of basing it off debian, installing gcc, and compiling redis from source :-) The image should be ~10MB.
Change:
$ cluster/kubecfg.sh -u=30s rollingupdate dataController Watch the UX, it will update one pod every 30 seconds until all of the pods have the new color. <ins> [cloud-console]: https://console.developer.google.com </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We need reporting of version to be shown in the metrics. Why is this needed: The goal behind this is to add some info about the underlying infrastructure for the kubernetes cluster. Some customers were experiencing issues during the cluster upgrades, but nothing in the upgrades themselves or kubernetes code for provider seemingly could cause those. The issue is storage related, and happening on a variety of releases with a significant delay from any other underlying infrastructure change, to which the kubernetes cluster has no relation and a way to know about. So knowing used hostnames, and versions associated with it over time would be extremely beneficial for debugging in similar circumstances. Some of the use cases we face: 1) A is enabled in a customer environment, and so there occurs a periodic automated vMotion for VMs backing kuberentes . We'd like to know on which host the actual kubernetes was located at any moment, and if any vCenter version transitions happened over time, new hosts /removed/renamed.
/sig cloud-provider /wg provider-vsphere
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cloud-provider /wg provider-vsphere 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
/area provider/vmware
Change:
return err } if recreated { <del> newF, err := os.Open(path) </del> <ins> newF, err := openFileShareDelete(path) </ins> if err != nil { if os.IsNotExist(err) { continue

Discussion:
The test is failing on Windows [0]: The idea of the test is to check that kubelet still follows and reads the Container Logs after a Log Rotation occured. However, because the followed file is open, it cannot be renamed, and thus, the container logs cannot be rotated. This issue could be prevented if the file would be opened with the [0] [1] Kubelet should not block container log rotation. Run the test ` is failing on Windows. /sig windows /kind bug /kind failing-test latest, master. This unit test has been failing for a while. N/A Windows nodes </detailsN/A N/A N/A
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
/kind failing-test /sig windows
Change:
RequestCount int } <ins> func init() { lookupIP = func(host string) ([]net.IP, error) { return nil, fmt.Errorf("lookup %v: no such host", host) } } </ins> func (c *FakeNodeHandler) Nodes() client.NodeInterface { return c }

Discussion:
It seems like this depends on the network condition as I first noticed this while on a plane, and it happens to me every so often but never on travis. Offenders are TestSyncNodeStatusDeletePods and TestSyncNodeStatusTransitionTime. This may be reproducible by disconnecting network connection but also happens sometimes while connected. is a call to net.LookupIP(), I'll investigate more.
This also occurs on OSX over a VPN (at least, for my VPN it does). Each call to net.LookupIP(name) takes 30s and fails correctly. As a result, the entire unit test times out. That same function call fails fast on Linux.
cc
For other runtime, we can just mock out net, time. I'd really like to know how to do mocking in go. Using interface seems overkill.