jiebi/CodeConvo huggingface dataset:
Change:
return nil } <del> func NewTableSorter(table *metav1beta1.Table, field string) *TableSorter { </del> <ins> func NewTableSorter(table *metav1beta1.Table, field string) (*TableSorter, error) { </ins> var parsedRows [][][]reflect.Value parser := jsonpath.New("sorting").AllowMissingKeys(true) err := parser.Parse(field) if err != nil { <del> klog.Fatalf("sorting error: %vn", err) </del> <ins> return nil, fmt.Errorf("sorting error: %v", err) </ins> } <ins> fieldFoundOnce := false </ins> for i := range table.Rows { parsedRow, err := findJSONPathResults(parser, table.Rows[i].Object.Object) if err != nil { <del> klog.Fatalf("Failed to get values for %#v using %s (%#v)", parsedRow, field, err) </del> <ins> return nil, fmt.Errorf("Failed to get values for %#v using %s (%#v)", parsedRow, field, err) </ins> } parsedRows = append(parsedRows, parsedRow) <ins> if len(parsedRow) > 0 && len(parsedRow[0]) > 0 { fieldFoundOnce = true } } if len(table.Rows) > 0 && !fieldFoundOnce { return nil, fmt.Errorf("couldn't find any field with path %q in the list of objects", field) </ins> } return &TableSorter{ obj:        table, field:      field, parsedRows: parsedRows, <del> } </del> <ins> }, nil </ins> } func findJSONPathResults(parser *jsonpath.JSONPath, from runtime.Object) ([][]reflect.Value, error) { if unstructuredObj, ok := from.(*unstructured.Unstructured); ok {

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:
// Initialize passes a Kubernetes clientBuilder interface to the cloud provider func (c *Cloud) Initialize(clientBuilder controller.ControllerClientBuilder) { c.clientBuilder = clientBuilder <del> c.kubeClient = clientBuilder.ClientOrDie("cloud-provider") </del> <ins> c.kubeClient = clientBuilder.ClientOrDie("aws-cloud-provider") </ins> c.eventBroadcaster = record.NewBroadcaster() c.eventBroadcaster.StartLogging(glog.Infof) c.eventBroadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: v1core.New(c.kubeClient.CoreV1().RESTClient()).Events("")}) <del> c.eventRecorder = c.eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "aws-cloudprovider"}) </del> <ins> c.eventRecorder = c.eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "aws-cloud-provider"}) </ins> } // Clusters returns the list of clusters.

Discussion:
Recently introduced fix of tainting the node if EBS volume on a node is stuck for too long in "attaching" state does not work on RBAC enabled clusters because of missing service account permissions. /sig storage /sig aws
Change:
{Name: "net.ipv4.ip_unprivileged_port_start", Value: "1024"}, {Name: "net.ipv4.ip_local_reserved_ports", Value: "1024-4999"}, {Name: "net.ipv4.tcp_keepalive_time", Value: "7200"}, <ins> {Name: "net.ipv4.tcp_fin_timeout", Value: "60"}, {Name: "net.ipv4.tcp_keepalive_intvl", Value: "75"}, {Name: "net.ipv4.tcp_keepalive_probes", Value: "9"}, </ins> } }), }

Discussion:
Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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
/sig node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted
Change:
... ``` <del> If you don't specify master and minion sizes, the scripts will attempt to guess the correct size of the master and worker nodes based on `${NUM_NODES}`. In particular, for clusters less than 50 nodes it will use a `t2.micro`, for clusters between 50 and 150 nodes it will use a `t2.small` and for clusters with greater than 150 nodes it will use a `t2.medium`. </del> <ins> If you don't specify master and minion sizes, the scripts will attempt to guess the correct size of the master and worker nodes based on `${NUM_NODES}`. In version 1.2 these default are: * For the master, for clusters of less than 150 nodes it will use an `m3.medium`, for clusters of greater than 150 nodes it will use an `m3.large`. * For worker nodes, for clusters less than 50 nodes it will use a `t2.micro`, for clusters between 50 and 150 nodes it will use a `t2.small` and for clusters with greater than 150 nodes it will use a `t2.medium`. </ins> WARNING: beware that `t2` instances receive a limited number of CPU credits per hour and might not be suitable for clusters where the CPU is used consistently. As a rough estimation, consider 15 pods/node the absolute limit a `t2.large` instance can handle before it starts exhausting its CPU credits steadily, although this number depends heavily on the usage. <ins> In prior versions of kubernetes, we defaulted the master node to a t2-class instance, but found that this sometimes gave hard-to-diagnose problems when the master ran out of memory or CPU credits.  If you are running a test cluster and want to save money, you can specify `export MASTER_SIZE=t2.micro` but if your master pauses do check the CPU credits in the AWS console. For production usage, we recommend at least `export MASTER_SIZE=m3.medium` and `export NODE_SIZE=m3.medium`.  And once you get above a handful of nodes, be aware that one m3.large instance has more storage than two m3.medium instances, for the same price. We generally recommend the m3 instances over the m4 instances, because the m3 instances include local instance storage.  Historically local instance storage has been more reliable than AWS EBS, and performance should be more consistent. The ephemeral nature of this storage is a match for ephemeral container workloads also! If you use an m4 instance, or another instance type which does not have local instance storage, you may want to increase the `NODE_ROOT_DISK_SIZE` value, although the default value of 32 is probably sufficient for the smaller instance types in the m4 family. </ins> The script will also try to create or reuse a keypair called "kubernetes", and IAM profiles called "kubernetes-master" and "kubernetes-minion". If these already exist, make sure you want them to be used here.

Discussion:
I propose that we default to for the master node (and maybe for 150 nodes?). We've seen problems with running out of memory on the master with the , and we've seen pauses that look like CPU exhaustion on the t2 class in general. Also the master is the hardest instance to resize. It is doable to reconfigure the ASG for the nodes (or add a new one, but the master is tricky). what do you think? cc
Change:
ginkgo.By("creating") eps1 := epsTemplate.DeepCopy() eps1.Endpoints = []discoveryv1.Endpoint{ <del> {Addresses: []string{pod1.Status.PodIP}}, </del> <ins> { Addresses:  []string{pod1.Status.PodIP}, Conditions: discoveryv1.EndpointConditions{Ready: &readyCondTrue}, }, </ins> } eps1.Ports = []discoveryv1.EndpointPort{{ Name:     pointer.String("port80"),

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

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?: /kind bug What happened: there will be azure disk creation issue when specifying an external resource group, after azure disk creation succeeded, it fails to get azure disk state What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign /azure
/sig azure
/kind bug
Change:
cfg:      &kubeadmapi.NodeConfiguration{}, expected: false, }, <ins> { cfg: &kubeadmapi.NodeConfiguration{ DiscoveryTokenAPIServers: []string{"192.168.1.15"}, }, expected: false, }, { cfg: &kubeadmapi.NodeConfiguration{ DiscoveryTokenAPIServers: []string{"2001:1234::1:15"}, }, expected: false, }, </ins> } for _, rt := range tests {

Discussion:
BUG REPORT /kind bug What happened: Kubeadm checks that bridge-nf-call-iptables (IPv4) is set, but does not check for bridge-nf-call-ip6tables (IPv6) What you expected to happen: If IPv6 is being used, then Kubeadm should check for bridge-nf-call-ip6tables How to reproduce it (as minimally and precisely as possible): Just running Kubeadm, however it's only a problem when running IPv6 Anything 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:
/area ipv6 /area kubeadm
/sig network
Change:
labels: app: cockroachdb annotations: <del> scheduler.alpha.kubernetes.io/affinity: > { "podAntiAffinity": { "preferredDuringSchedulingIgnoredDuringExecution": [{ "weight": 100, "labelSelector": { "matchExpressions": [{ "key": "app", "operator": "In", "values": ["cockroachdb"] }] }, "topologyKey": "kubernetes.io/hostname" }] } } </del> # Init containers are run only once in the lifetime of a pod, before # it's started up for the first time. It has to exit successfully # before the pod's main containers are allowed to start.

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: Check , it is still using , we should move it to . What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
/assign
probably will want to move the init container also to the PodSpec
I think the init container still depend on annotations , can I specify in ? If so, I want to file another issue to track it
FYI Init containers have graduated to GA and now appear as a field. The beta annotation value will still be respected and overrides the field value. (,
Seems like that the doc should be updated. EDIT: NOTE: This feature is beta in Kubernetes 1.5. Once the feature exits beta, Init Containers will be specified in the PodSpec alongside the app containers array.
Thanks I filed an issue here
What about merge this first and then handle init-container in a separate PR?
Sounds good to me, thanks.
Change:
// add old missing cache data with nil entries to prevent aggressive // ARM calls during cache invalidation for name, vmEntry := range oldCache { <del> // if the nil cache entry has existed for 15 minutes in the cache </del> <ins> // if the nil cache entry has existed for vmssVirtualMachinesCacheTTL in the cache </ins> // then it should not be added back to the cache <del> if vmEntry.virtualMachine == nil && time.Since(vmEntry.lastUpdate) > 15*time.Minute { </del> <ins> if vmEntry.virtualMachine == nil && time.Since(vmEntry.lastUpdate) > vmssVirtualMachinesCacheTTL { </ins> klog.V(5).Infof("ignoring expired entries from old cache for %s", name) continue }

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: When a node is deleted and then recreated in short time, the "instance not found" error would be reported from Azure cloud provider and hence the node object is deleted by kube-controller-manager. It is because the deleted VMSS VM would be cached for 15 minutes (this is used to avoid throttling issues when a large number of nodes are deleted): The cache above is too long and should be reduced to a shorter value, e.g. 3 minutes. What you expected to happen: The newly created Node should not be deleted. 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: /kind bug /priority critical-urgent /area provider/azure /sig cloud-provider
is anyone already working on this?
is working on a fix for this. Would you like to have a look?
will do
Thank you for working on this, and /assign
Change:
// RunIfContainerRuntimeIs runs if the container runtime is included in the runtimes. func RunIfContainerRuntimeIs(runtimes ...string) { for _, containerRuntime := range runtimes { <del> if containerRuntime == TestContext.ContainerRuntime { </del> <ins> if containerRuntime == framework.TestContext.ContainerRuntime { </ins> return } } <del> skipInternalf(1, "Skipped because container runtime %q is not in %s", TestContext.ContainerRuntime, runtimes) </del> <ins> skipInternalf(1, "Skipped because container runtime %q is not in %s", framework.TestContext.ContainerRuntime, runtimes) </ins> } // RunIfSystemSpecNameIs runs if the system spec name is included in the names. func RunIfSystemSpecNameIs(names ...string) { for _, name := range names { <del> if name == TestContext.SystemSpecName { </del> <ins> if name == framework.TestContext.SystemSpecName { </ins> return } } <del> skipInternalf(1, "Skipped because system spec name %q is not in %v", TestContext.SystemSpecName, names) </del> <ins> skipInternalf(1, "Skipped because system spec name %q is not in %v", framework.TestContext.SystemSpecName, names) </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: Flexvolume e2e tests are skipped in https://k8s-, so as far as I can tell we don't have Flexvolume test coverage. They are skipped because they require SSH access to drop the Flexvolume plugin onto the host, but these test clusters do not have SSH access. We should change all Flexvolume tests to use the DaemonSet installation mechanism instead which does not require SSH access. See and Flexvolume tests I'm aware of are below, but there could be more: Looking for help with this bug! /sig storage /priority important-soon /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : <!-- 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: Flexvolume e2e tests are skipped in https://k8s-, so as far as I can tell we don't have Flexvolume test coverage. /priority important-soon /help 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
Hi, Can I work on this issue? I think i know how to handle it.
are you still working on this? I'm interested in helping out as well.
/assign
Change:
kube::etcd::install() { ( <ins> local os </ins> cd "${KUBE_ROOT}/third_party" <del> if [[ $(readlink etcd) == etcd-v${ETCD_VERSION}-* ]]; then </del> <ins> os=$(uname | tr "[:upper:]" "[:lower:]") if [[ $(readlink etcd) == etcd-v${ETCD_VERSION}-${os}-* ]]; then </ins> return  # already installed fi <del> if [[ $(uname) == "Darwin" ]]; then </del> <ins> if [[ ${os} == "darwin" ]]; then </ins> download_file="etcd-v${ETCD_VERSION}-darwin-amd64.zip" url="https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/${download_file}" kube::util::download_file "${url}" "${download_file}"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: During k8s cluster launch, is checked and if any etcd binary is found regardless of current OS Distribution, expected etcd binary is not downloaded and etcd soft link is not updated to point desired etcd binary, so cluster creation fails. What you expected to happen: Along with expected etcd version, OS Distribution should also be checked for successfully and efficiently installing etcd during setting up local cluster. How to reproduce it (as minimally and precisely as possible): Checkout k8s codbase on MacOS and launch cluster. working k8s codebase under virtual machine to launch cluster in VM. (Cluster creation would fail, prompting error that etcd needs to be installed and update in {KUBEROOT}/thirdparty/etcd-v{ETCDVERSION}-linux-* Anything else we need to know?: It's an optimization on managing thirdparty etcd binary for local cluster setup. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
do you have a patch that you are working on? we don't really support local-up-cluster on macos yet. /sig testing
is fixing this issue. Though I use Mac as my workstation but sometimes need local-cluster to test codebase so I mapped (softlinked) my GOPATH in virtual machine keeping separate bin directory. Everything is running perfectly fine after making changes mentioned in this PR. So thought to submit small optimization on etcd installation logic.
/close
Change:
sharedConcurrencyMetricsName      = "apiserver_flowcontrol_request_concurrency_limit" dispatchedRequestCountMetricsName = "apiserver_flowcontrol_dispatched_requests_total" rejectedRequestCountMetricsName   = "apiserver_flowcontrol_rejected_requests_total" <del> labelPriorityLevel                = "priorityLevel" </del> <ins> labelPriorityLevel                = "priority_level" </ins> timeout                           = time.Second * 10 )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : API priority and fairness metrics have labels such as "priorityLevel" and "flowSchema". These should be "prioritylevel" and "flowschema" respectively. These metrics have been to an exception list: Why is this needed: snake_case is consistent with other metrics. /sig api-machinery /kind cleanup /cc Do we want to do this before 1.20 beta?
yes, lets do that.
/triage accepted Yes, we do not want to go to beta with known wrongness in the metrics.