jiebi/CodeConvo huggingface dataset:
Change:
"github.com/coreos/go-etcd/etcd" ) <del> type fakeClientGetSet struct { get func(key string, sort, recursive bool) (*etcd.Response, error) set func(key, value string, ttl uint64) (*etcd.Response, error) } </del> type TestResource struct { api.TypeMeta   `json:",inline"` api.ObjectMeta `json:"metadata"`

Discussion:
kubectl returns resources in a random order, which makes it hard to look for things when users have a lot resources. Returning resources in deterministic order should be a helpful and trivial change (hopefully). We have an issue about pagination , but that's a larger and separate issue.
We should be cause to not do this on the * namespace - I think thats a special case. No disagreement for other list calls
What is the default etcd response order? Last created or last modified? Sent from my iPhone
I think the order is by key if sort param is given. If not given, the order is by last created (maybe, but we shouldn't trust it). It seems we are not trying to get sorted result from etcd.
Today, I think it's random order in the child key space in etcd (because the node structure uses a map), so you get golang map iteration order without sort. I don't know if sort on server is any cheaper than sort on client today, so we may want to do this in rest / registry rather than by passing etcd.
Apart from performance, sorting in clients means we can also take control of how responses are sorted, so for * namespace, we can sort by namespace, then by resource ID. , Clayton Coleman wrote: Master of Electrical and Computer Engineering Carnegie Mellon University
We can always hint sort to the registry storage layer in the future, so sorting on the client now won't kill us.
Just took a closer look at our rest/registry code to implement the sort (in client), but implementation-wise, it seems much easier to pass sort to etcd (one line change). Also, namespace is a prefix on resource, so sort across all namespace with etcd key will essentially sort resources by namespace then by Name. If we are to implement sort on client side, we can either: sort package: have each list object, ie.e PodList, ControllerList, implement sort interface. (We won't do this). have ListMeta implement sort interface, if there is a way to find enclosing structs (so we can use items field) have api.Object implement sort interface, verify object is list before sorting. sort algorithm ourself, and do it in rest. Is there other golang or kubernetes idom that I haven't been aware of that can be applied to this use case?

----- Original Message ----- I think sorting it on etcd is fine for now - that's the simplest possible thing that works.
Is there any material perf impact in etcd to enable it? Sent from my iPhone
Probably not material. Can always switch away if necessary
Famous last words :-) Sent from my iPhone
Got my hat ready
Change:
"bytes" "encoding/json" "fmt" <ins> "github.com/pkg/errors" "math" </ins> "strconv" "strings" "k8s.io/kubernetes/test/e2e/framework" ) <del> // IPerfResults is a struct that stores some IPerfResult </del> <ins> const ( megabyte = 1024 * 1024 ) // IPerfResults is a struct that stores some IPerfCSVResult </ins> type IPerfResults struct { BandwidthMap map[string]int64 } <del> // IPerfResult struct modelling an iperf record.... </del> <ins> // IPerfCSVResult struct modelling an iperf record.... </ins> // 20160314154239,172.17.0.3,34152,172.17.0.2,5001,3,0.0-10.0,33843707904,27074774092 <del> type IPerfResult struct { </del> <ins> type IPerfCSVResult struct { </ins> date          string // field 1 in the csv cli           string // field 2 in the csv cliPort       int64  // ...

Discussion:
What happened: The iperf tests were written a while ago but i think havent been updated. They measure bandwidth over multiple pods, but they probably should also have a test which reports individual pod's bandwidth between one pod over a SEP. They should pretty print a table so its easy to see exactly what is going on with the bandwidth They should use iperf3 (need to check that) Maybe we should have permutations for udp and tcp? The current output is something like: What you expected to happen: That running the tests would result in a table such as those that you can get from iperf3, i.e. How to reproduce it: run the e2es on any cluster, Environment: Kubernetes version (use ): master, any version
/sig network
/assign
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I've taken a first pass at this , working on resolving a couple issues then we can circle back to determine how else it could be improved!
Cool c/p the new test output so we can compare when u get a chance
ah yess. much better then what we have now.
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:
framework.ExpectEqual(resp.StatusCode, 301, "The resp.StatusCode returned: %d", resp.StatusCode) } <del> func checkPodStatus(f *framework.Framework, label string) func() (bool, error) { return func() (bool, error) { var err error list, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).List(context.TODO(), metav1.ListOptions{ LabelSelector: label}) if err != nil { return false, err } if list.Items[0].Status.Phase != "Running" { framework.Logf("Pod Quantity: %d Status: %s", len(list.Items), list.Items[0].Status.Phase) return false, err } framework.Logf("Pod Status: %v", list.Items[0].Status.Phase) return true, nil } } </del> // validateProxyVerbRequest checks that a http request to a pod // or service was valid for any http verb. Requires agnhost image // with porter --json-response

Discussion:
pull-kubernetes-e2e-kind-ipv6 - Not sure. Time out on waiting Pod to be started. No response /sig network
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:
utilstrings "k8s.io/utils/strings" ) <ins> func getPath(uid types.UID, volName string, host volume.VolumeHost) string { return host.GetPodVolumeDir(uid, utilstrings.EscapeQualifiedName(nfsPluginName), volName) } </ins> // ProbeVolumePlugins is the primary entrypoint for volume plugins. <ins> // This is the primary entrypoint for volume plugins. </ins> // The volumeConfig arg provides the ability to configure recycler behavior.  It is implemented as a pointer to allow nils. // The nfsPlugin is used to store the volumeConfig and give it, when needed, to the func that creates NFS Recyclers. // Tests that exercise recycling should not use this func but instead use ProbeRecyclablePlugins() to override default behavior.

Discussion:
/kind feature What happened: on a cluster with an nfs persistent volume present: What you expected to happen: I expected metrics concerning the nfs persistent volume to be returned e.g: (from a separate aws cluster) Anything else we need to know?: I'm assuming that this is just not implemented currently? I couldn't find a referencing issue Environment: Kubernetes version (use ):Cloud provider or hardware configuration: on-prem OS (e.g. from /etc/os-release):Kernel (e.g. ):
/sig instrumentation
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
/open Metrics is missing for NFS driver.
/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
/remove-lifecycle rotten
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
/sig storage
Change:
} } <ins> client := NewDiscoveryClientForConfigOrDie(&restclient.Config{Host: server.URL}) start := time.Now() </ins> serverResources, err := client.ServerResources() if err != nil { t.Errorf("unexpected error: %v", err) } <ins> end := time.Now() if d := end.Sub(start); d > time.Second { t.Errorf("took too long to perform discovery: %s", d) } </ins> serverGroupVersions := groupVersions(serverResources) <del> expectedGroupVersions := []string{"v1", "extensions/v1beta1", "extensions/v1beta2"} </del> <ins> expectedGroupVersions := []string{ "v1", "apps/v1beta1", "apps/v1beta2", "apps/v1beta3", "apps/v1beta4", "apps/v1beta5", "apps/v1beta6", "apps/v1beta7", "apps/v1beta8", "apps/v1beta9", "apps/v1beta10", "extensions/v1beta1", "extensions/v1beta2", "extensions/v1beta3", "extensions/v1beta4", "extensions/v1beta5", "extensions/v1beta6", "extensions/v1beta7", "extensions/v1beta8", "extensions/v1beta9", "extensions/v1beta10", } </ins> if !reflect.DeepEqual(expectedGroupVersions, serverGroupVersions) { t.Errorf("unexpected group versions: %v", diff.ObjectReflectDiff(expectedGroupVersions, serverGroupVersions)) }

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: With client-go v0.17.0, I observed many "Throttling request" when DiscoveryClient is used to get API group resources from API server. This didn't happen with client-go kubernetes-1.16.0. It looks like originally this kind of discovery requests are not throttled because no rate limiter provided and QPS == 0. But with rate limiter is always set if nil rate limiter is provided. is particularly suspicious because it is always true because DefaultQPS is nonzero. What you expected to happen: Discovery requests should not be throttled as before. How to reproduce it (as minimally and precisely as possible): Create DiscoveryClient and then call with it. 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 api-machinery
The NewTokenBucketRateLimiter was via Always negotiate a decoder using ClientNegotiator /cc
To be clear, that was fixing a bug where the documented defaults for rate limiting were not taking effect. I don't think we should completely disable throttling until more of the server-side priority work is completed, but discovery is expected to be bursty, so I could see defaulting to a different amount in the discovery client constructor, similar to
Yeah, everyone must be rate limited. I think we could give discovery a big burst value.
opened
Change:
"strconv" "sync" <ins> "k8s.io/kubernetes/pkg/api/errors" </ins> "k8s.io/kubernetes/pkg/api/meta" "k8s.io/kubernetes/pkg/client/cache" "k8s.io/kubernetes/pkg/runtime"

Discussion:
We sorta fixed this-- now it's a real status error, but we left the status code 500, so it still produces stack traces and potentially confuses clients. we should figure out the correct status code.
I think there is a lot more going on related to this in . Clients are re-listing after the error but not rewatching.
/sub
It turned out this was not causing job e2e flakes. Just sending 500s that were confusing. So lowering priority.
How about a NewBadRequest error?
that certainly sounds like an improvement.
Change:
rbacv1helpers.NewRule("update").Groups(appsGroup).Resources("statefulsets/finalizers").RuleOrDie(), rbacv1helpers.NewRule("get", "create", "delete", "update", "patch").Groups(legacyGroup).Resources("pods").RuleOrDie(), rbacv1helpers.NewRule("get", "create", "delete", "update", "patch", "list", "watch").Groups(appsGroup).Resources("controllerrevisions").RuleOrDie(), <del> rbacv1helpers.NewRule("get", "create").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie(), </del> <ins> rbacv1helpers.NewRule("get", "create", "list", "watch").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie(), </ins> eventsRule(), }, } if utilfeature.DefaultFeatureGate.Enabled(features.StatefulSetAutoDeletePVC) { role.Rules = append(role.Rules, rbacv1helpers.NewRule("update", "delete").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie()) <ins> role.Rules = append(role.Rules, rbacv1helpers.NewRule("update").Groups(legacyGroup).Resources("pods/finalizers").RuleOrDie()) </ins> } return role

Discussion:
When OwnerReferencesPermissionEnforcement admission plugin is used the PVCs are not deleted and KCM logs show PVCs should have ownerReferences set and the PVCs should be garbage collected on scale down 3 of 6 of the following tests fail when OwnerReferencesPermissionEnforcement admission plugin is turned on No response <details</details<detailsNA </details<details</details<details</details<details</details<details</details
/sig apps /triage accepted
Change:
extension = "tar.gz", package_dir = "kubernetes", strip_prefix = "//", <ins> symlinks = { "kubernetes/cluster/gce/cos/": "gci", "kubernetes/cluster/gce/custom/": "gci", "kubernetes/cluster/gce/ubuntu/": "gci", }, </ins> tags = ["no-cache"], deps = [ ":_full_server",

Discussion:
What happened: that uses Ubuntu image fails during Kubernetes installation: Full log: Indeed, is not present on nodes. Only and subdirectories are present in . I don't know what code removed (or did not package) and symlinks, but they should be there. What you expected to happen: Kubernetes is installed correctly and e2e tests start. How to reproduce it (as minimally and precisely as possible): Run in a PR. Anything else we need to know?: Prow job: It seems to be the only one that uses Ubuntu image. This command works and installs Kubernetes correctly: is present there. Dunno what the prow job does differently.
/sig testing
the nodes receive files staged via the release scripts and downloaded by the cluster/ scripts, I don't think sig testing will be the right group to fix this. SIG node has some owners related to the various images that might have some idea how this is setup
/sig release this is probably an issue in the release scripts
cc:
PTAL, it looks like a stupid bug somewhere.
Q: Did this ever run successfully?
Most probably not, I haven't found a working e2e tests on Ubuntu. Still, works well, there must be something slightly different in test setup scripts.
ping again? Short recap: This works: is there. ( is symlink to ) This does not work: Fails with: does not exist. The prow job must do something slightly different than kube-
The serial job is using GCI (COS): Is the non-serial job working? It uses ubuntu: If not, my guess from the last time I remember looking was checking the release bundle and ensuring it includes the ubuntu dir
No, same error. created by contains , released bundles (e.g. ) contains it too. Otherwise would not work with an Ubuntu image. So what does the prow job differently? Does something there prune the scripts? is just a symlink to , does it make a difference?
Found it, creates without any symlinks. It looks like bazel limitation. I filled to explicitly create the symlinks when tarball is created. BTW, if and use different way to produce tarballs, who / when tests the ones created by ?
Most of CI is using make release or equivalent. Presumbit uses bazel. Jan Šafránek <:
/area release-eng /milestone v1.16 /priority important
/priority important-soon
Change:
) go_genrule( name = "zz_generated.openapi", <del> srcs = srcs + ["//hack/boilerplate:boilerplate.go.txt"], </del> <ins> srcs = srcs + ["//" + vendor_prefix + "hack/boilerplate:boilerplate.go.txt"], </ins> outs = ["zz_generated.openapi.go"], cmd = " ".join([ "$(location //vendor/k8s.io/code-generator/cmd/openapi-gen)", "--v 1", "--logtostderr", <del> "--go-header-file $(location //hack/boilerplate:boilerplate.go.txt)", </del> <ins> "--go-header-file $(location //" + vendor_prefix + "hack/boilerplate:boilerplate.go.txt)", </ins> "--output-file-base zz_generated.openapi", <del> "--output-package k8s.io/kubernetes/pkg/generated/openapi", "--input-dirs " + ",".join(["k8s.io/kubernetes/" + target for target in openapi_targets] + ["k8s.io/kubernetes/vendor/" + target for target in vendor_targets]), "&& cp pkg/generated/openapi/zz_generated.openapi.go $(location :zz_generated.openapi.go)", </del> <ins> "--output-package " + go_prefix + vendor_prefix + "pkg/generated/openapi", "--input-dirs " + ",".join([go_prefix + target for target in openapi_targets] + [go_prefix + "vendor/" + target for target in vendor_targets]), "&& cp " + vendor_prefix + "pkg/generated/openapi/zz_generated.openapi.go $(location :zz_generated.openapi.go)", </ins> ]), go_deps = deps, tools = ["//vendor/k8s.io/code-generator/cmd/openapi-gen"],

Discussion:
As part of moving federation out of tree (), the federation build will need to generate ` for itself and vendored kubernetes. The following steps are required: [x] Discover targets for generation () [x] Update the file's bazel rules to configurably enable a build for vendored kube () [x] Support generation of the file to a vendored path () [x] Update kubernetes to use latest kazel and kube-openapi () /sig multicluster testing /area federation /assign cc:
/cc
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
// Queried from cloud provider, if available. Addresses []NodeAddress `json:"addresses,omitempty" description:"list of addresses reachable to the node" patchStrategy:"merge" patchMergeKey:"type"` // NodeSystemInfo is a set of ids/uuids to uniquely identify the node <del> NodeInfo NodeSystemInfo `json:"nodeInfo,omitempty"` </del> <ins> NodeInfo NodeSystemInfo `json:"nodeInfo,omitempty" description:"set of ids/uuids to uniquely identify the node"` </ins> } type NodePhase string

Discussion:
PR had a few errors in its API objects, where the "description" field errors in its JSON declarations were missing. But, the "verify-" presubmit check didn't flag them. This should be investigated and fixed.
Could you please take a look at this?
Change:
Name:      "node2mirrorpod", Namespace: "ns", }, <ins> DeleteOptions: &metav1.DeleteOptions{GracePeriodSeconds: &zero}, </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!--What happened: When using the function from Python's Kuberneets API, we noticed that Pods are terminated bythe cluster without respecting their preStop hooks or terminationGracePeriodSeconds seconds. What you expected to happen: When using the eviction API, just as when using delete, Pods should be allowed to run their preStop hooks, as well as be given terminationGracePeriodSeconds before being terminated with SIGKILL. How to reproduce it (as minimally and precisely as possible): the following pod: the pod logs in another window to evict the pod. Here is a sample curl equivalent of what (1.13) is doing - happy path: Here is a sample curl equivalent of what Python's is doing (when not passed ) - broken path: The log output generated by the guinea pod on the happy path looks like this: The "Got signal 15" message shows up only after the preStop hook is finished, so ~10 seconds after the evict call is made What happens on the broken path is: We seem to be getting 2x SIGTERM, there are no messages indicating continued processing after the signal, and the signal itself is registered immediately after the eviction call is made, suggesting that preStop didn't run. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CentOS Linux release 7.5.1804 Kernel (e.g. ): 3.10.0-862.14.4.el7.x8664 SMP Wed Sep 26 15:12:11 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: in-house Others:
/sig api-machinery
this is because of this code: invoked from here: it is passing in the eviction delete options field as-is, meaning nil gets propagated and defaulted to mean delete immediately. when calling delete APIs normally, delete options defaults to a non-nil empty set of options:
Fixed in
patch looks legit. Thanks for the quick reaction and for the pointers!
I've a elasticsearch stateful set which have a preHook which never completes and the pod is never killed despite terminationGracePeriodSeconds being set.

Is it related ? If so can this be considered to be cherry-picked on v1.13.x release branch ?
Change:
{"1234/5678": "bar"}, {"1.2.3.4/5678": "bar"}, {"UpperCase123": "bar"}, <del> {"a": strings.Repeat("b", totalAnnotationSizeLimitB-1)}, </del> <ins> {"a": strings.Repeat("b", TotalAnnotationSizeLimitB-1)}, </ins> { <del> "a": strings.Repeat("b", totalAnnotationSizeLimitB/2-1), "c": strings.Repeat("d", totalAnnotationSizeLimitB/2-1), </del> <ins> "a": strings.Repeat("b", TotalAnnotationSizeLimitB/2-1), "c": strings.Repeat("d", TotalAnnotationSizeLimitB/2-1), </ins> }, } for i := range successCases {

Discussion:
Expose totalAnnotationSizeLimitB in the validation package: This value is useful for validating annotations outside of the validation package, such as in SSA: Otherwise, size validation on annotations outside of the package would diverge and cause issues later. /kind cleanup /wg api-expression 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
/assign