jiebi/CodeConvo huggingface dataset:
Change:
}, metricsName: "scheduler_pending_pods", wants: ` <del> # HELP scheduler_pending_pods [ALPHA] Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ. </del> <ins> # HELP scheduler_pending_pods [STABLE] Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ. </ins> # TYPE scheduler_pending_pods gauge scheduler_pending_pods{queue="active"} 50 scheduler_pending_pods{queue="backoff"} 0

Discussion:
I would like to propose the graduation of the following scheduler metrics from alpha to stable: These metrics have been stable for at least 15 months.
/sig scheduling /sig instrumentation
/cc
IIRC, the last addition to these metrics was the profile name label. I don't foresee need for new labels. I don't see many precedents for graduation in core components. are there any defined criteria for graduation?
As requested, the following is how long it has been since a change has been made to each of the requested metrics: - 2 years; last change was to migrate to the metrics stability framework - 17 months; last change was a renaming of the metric - 15 months; last change was a renaming of the metric - 17 months; last change was to add a label - 17 months; last change was to add a label
It's up to the component owners to commit to graduating these metrics, since the component owners own the metrics and therefore need to agree to support them in accordance to stability requirements. If you guys are okay with promoting these metrics, I don't see a reason, from an instrumentation side, why we would object to promotion.
+1 to graduation then. These metrics are very mature. Although, I'm not sure if all metrics already adhere to naming conventions. and don't have a unit suffix, but they are unit-less. Is that fine
is a gauge so it's fine, is a histogram so it's also fine.
I'm recently working with metrics, I'm glad to provide some help if no one has interest about it.
There is already an open PR for this.
Oh sorry, didn't notice about that. Forget it.
These graduations sound good to me, but I would be inclined to rename . I feel that the part of the metric is unnecessary. Having instead and keeping for the algorithm latency is already descriptive enough to know the difference between both. If that's not the case, then the text of the metric can be used to guide the users.
I agree that is rather confusing, so +1 to removing the prefix. The metric doesn't include retries, for example. We have a separate metric that includes retries: We need to rename that one eventually to e2e, but it can only be done after the existing one has been deprecated and deleted for a few releases. /triage accepted
/assign
/cc
The PR for this is ready to be reviewed:
Change:
// mockgen _ "github.com/golang/mock/mockgen" <ins> // tools like cpu _ "go.uber.org/automaxprocs" </ins> )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : should detect the appropriate GOMAXPROCS based off of the cpu limit supplied to the pod. Why is this needed: If not, test failures can occur (e.g. ) where GOMAXPROCS defaults to the number of cpus on the machine, while the cpu limit is actually far less. Too many compile/test processes launch, and any timing tests can become flaky. The end result is that running the test jobs on a node with more CPUs can make it flaky when running the test on a node with fewer CPUs cleanly passes. It's possible to set GOMAXPROCS=cpu limits in test jobs to avoid this, but it would be nicer if would autodiscover and set GOMAXPROCS appropriately.
/sig testing /sig k8s-infra
/transfer kubernetes
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 dims
xref:
This is already done, which is great, but for some more info I did some benchmarking of setting GOMAXPROCs vs not: Pretty substantially better in some cases
Change:
type HTTPIngressPath struct { // 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 Path string

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:
// updates labels of nodes given by nodeNames. // In case a given label already exists, it overwrites it. If label to remove doesn't exist // it silently ignores it. <ins> // TODO: migrate to use framework.AddOrUpdateLabelOnNode/framework.RemoveLabelOffNode </ins> func updateNodeLabels(c *client.Client, nodeNames sets.String, toAdd, toRemove map[string]string) { const maxRetries = 5 for nodeName := range nodeNames {

Discussion:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that NodeSelector is respected if matching [Conformance] {Kubernetes e2e suite}
Change:
pvc := createPVC("pvc-2", strconv.Itoa(maxPVs/2)+"G", []api.PersistentVolumeAccessMode{api.ReadWriteOnce}) <del> w, _ := testClient.PersistentVolumes().Watch(api.ListOptions{}) </del> <ins> w, err := testClient.PersistentVolumes().Watch(api.ListOptions{}) if err != nil { t.Errorf("Failed to watch PersistentVolumes: %v", err) } </ins> defer w.Stop() for i := 0; i < maxPVs; i++ { <del> _, _ = testClient.PersistentVolumes().Create(pvs[i]) </del> <ins> _, err = testClient.PersistentVolumes().Create(pvs[i]) if err != nil { t.Errorf("Failed to create PersistentVolume %d: %v", i, err) } </ins> } <del> _, _ = testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(pvc) </del> <ins> _, err = testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(pvc) if err != nil { t.Errorf("Failed to create PersistentVolumeClaim: %v", err) } </ins> // wait until the controller pairs the volume and claim waitForPersistentVolumePhase(w, api.VolumeBound)

Discussion:
PersistentVolume integration tests fail sometimes: There are some interesting reports in the log like: Thans for report.
It turns out that volume integration tests have no logs at all, was not checked and I don't really know what's going on there. adds error checks to help me find out what's wrong there. Still, I suspect there are some troubles with etcd, not related to the test itself.
This flake affects also TestPersistentVolumeMultiPVs:
Extended logging got merged just now, please post links to logs when it breaks again!
Marking as P1 as per
I have no real usable logs, but I think it could be fixed by , it hasn't flaked since it was merged. And I have (in merge queue) to further stabilize the tests.
Not blocking this on 1.3.
It hasn't flaked for almost a month, can we close this?
Closing this issue since previous fixes made the flake go away.
Change:
// // If the webhook is running within the cluster, then you should use `service`. // <del> // If there is only one port open for the service, that port will be // used. If there are multiple ports open, port 443 will be used if it // is open, otherwise it is an error. </del> <ins> // Port 443 will be used if it is open, otherwise it is an error. </ins> // // +optional Service *ServiceReference

Discussion:
What happened: Deployed a webhook backend and service as follows: Please note that there is only 8443 port on the service. Register the webhook as follows: Got the following error when creating pods: What you expected to happen: Based on , should be called. Not the 443 port shown in the error message. How to reproduce it (as minimally and precisely as possible): Just deploy the same setup and register webhook. Anything else we need to know?: Environment: Kubernetes version (use ): HEAD Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.0-alpha.1.97+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2018-01-22T20:00:24Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.470+", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-03-12T19:36:42Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): COS Kernel (e.g. ): COS
thanks for the detailed bug report!
I actually think that the API specification (or documentation) must change. Not all API servers will have access to look up the Service object and see what ports it defines. If we want to support ports other than 443, the port information must be specified in the webhook object, not discovered by direct Service object lookup
/assign
Looks like it will always use 443 no matter what ports are available, right? Should our documentation reflect this or should it behave differently? (also just sets 443 in the custom dial wrapper thing )
As a first step, I would adjust the documentation. As noted in , if we want to support ports other than 443, that information needs to be to the webhook config object
Change:
} <del> // FromUnstructuredWIthValidation converts an object from map[string]interface{} representation into a concrete type. </del> <ins> // FromUnstructuredWithValidation converts an object from map[string]interface{} representation into a concrete type. </ins> // It uses encoding/json/Unmarshaler if object implements it or reflection if not. // It takes a validationDirective that indicates how to behave when it encounters unknown fields. func (c *unstructuredConverter) FromUnstructuredWithValidation(u map[string]interface{}, obj interface{}, returnUnknownFields bool) error {

Discussion:
I have created the following secret in my cluster. When I add labels to my secret and try to apply it in the cluster I get the following error This also happens when I use or using the go client. Not sure why, but works. I expect that the secret can be updated with the new labels since the is not actually changed. Steps explained above. No response <details</details<detailsKind </details<details</details<details</details<details</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 cli
/assign
/remove-sig cli /sig apps
Change:
<ins> package(default_visibility = ["//visibility:public"]) </ins> licenses(["notice"]) load(

Discussion:
StatefulSet now as of 1.6. That means the TODO on can be fixed in 1.7. We could not fix it in 1.6 because that code is used by kubectl, which must work against servers that are one minor version ahead of or behind the client.
/cc
I am volunteered to take this job if no one start working on this.
I don't think anyone's working on it, so you are welcome to take it. Feel free to tag me as a reviewer. Thanks!
Change:
ready := 0 for i := range pods.Items { pod := pods.Items[i] <del> if podutil.IsPodReady(&pod) { </del> <ins> if podutil.IsPodReady(&pod) && pod.ObjectMeta.DeletionTimestamp.IsZero() { </ins> ready++ } }

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: all of the e2e jobs that run this test Which test(s) are flaking: ` Testgrid link: Reason for failure: mostly: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated /sig apps xref:
approx:
my suspicion: /
I can't find anything else that seems relevant in the time frame, and it is the only change to the test file in that time frame.
merged recently, not sure if it's relevant
Not sure what the procedure it, but we can revert or try some other image instead of Pause, if you think it helps. I don't have a good explanation why the change would make the test flake like this.
I don't have a good explanation, just that it affects the test and is in the time frame that seems to fit the flake spike It may take a bit to pin down what exactly happened here :/ I can't look for a little bit.
I tried to reproduce this behaviour on a test cluster in AWS, but couldn't. I prepared a PR to revert the change, just incase.
Good news and bad news kind of thing... The same test fails in the revert PR also, with the previous EchoServer image:
I did an experiment reverting the second suspect in I couldn't reproduce the issue anymore even though I tried. You can check the results in the PR history.
I believe I have found the issue here. More information and fix incoming
Thanks for the update
I just about have a fix ready here. I was able to narrow the commit range to by looking at when this flake first occurred in It looks like was correct that this was introduced in . I believe what is happening is that in the test we are getting getting a with a set (the one that we previously successfully issued an eviction for) before waiting for 3 pods to be ready again in the namespace (). Before the aforementioned PR caused us to skip checking PDBs when is set we would still report back that eviction was not possible because our with did not meet the other criteria (i.e.

was not , , or ), which caused us to still check PDBs, which would show us that we did not have the budget to delete (even though it was not really taking into account the that we were actually attempting to evict). I think there are a few things we can do to address this: we should check that not only is the , but also that it does not have set. above where we call so that we do not attempt to get a before all of the pods are ready. in that the does not have a . Just doing (3) by itself would address our current problem, but (1) and (2) also seem to make sense in the context of what we are trying to check here.
Thanks everyone and apologies for the false alarm :-)
/lifecycle active /priority critical-urgent (this is blocking merges of other fixes) /assign
/milestone v1.19
Change:
output_message=$(kubectl auth can-i get pods --subresource=log --quiet 2>&1 "${kube_flags[@]}"; echo $?) kube::test::if_has_string "${output_message}" '0' <ins> # kubectl auth can-i get '*' does not warn about namespaced scope or print an error output_message=$(kubectl auth can-i get '*' 2>&1 "${kube_flags[@]}") kube::test::if_has_not_string "${output_message}" "Warning" # kubectl auth can-i get foo does not print a namespaced warning message, and only prints a single lookup error output_message=$(kubectl auth can-i get foo 2>&1 "${kube_flags[@]}") kube::test::if_has_string "${output_message}" "Warning: the server doesn't have a resource type 'foo'" kube::test::if_has_not_string "${output_message}" "Warning: resource 'foo' is not namespace scoped" # kubectl auth can-i get pods does not print a namespaced warning message or a lookup error output_message=$(kubectl auth can-i get pods 2>&1 "${kube_flags[@]}") kube::test::if_has_not_string "${output_message}" "Warning" # kubectl auth can-i get nodes prints a namespaced warning message output_message=$(kubectl auth can-i get nodes 2>&1 "${kube_flags[@]}") kube::test::if_has_string "${output_message}" "Warning: resource 'nodes' is not namespace scoped" # kubectl auth can-i get nodes --all-namespaces does not print a namespaced warning message output_message=$(kubectl auth can-i get nodes --all-namespaces 2>&1 "${kube_flags[@]}") kube::test::if_has_not_string "${output_message}" "Warning: resource 'nodes' is not namespace scoped" </ins> fi # kubectl auth reconcile

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 you expected to happen: if returns true I expect to be able to perform the action without issue. Note in this case my service user has a rolebinding in a single namespace (and that is also what my kubecontext is set to.) if I change my default to a different namespace then the command returns false How to reproduce it (as minimally and precisely as possible): create a namespace (test) create a service account in that namespace create a role that gives get list and watch permissions to create a rolebinding from that role to the service account. Anything else we need to know?: this is special because namespaces are not scoped to a namespace. if you replace the command with then you get the exepcted result however this breaks the path of least suprise. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig auth
asks the authorization system if the given verb can be performed on the given noun at the given scope. It does not interpret whether the resource exists at that scope. We could warn if we find the specified resource and it does not exist at the specified scope (just like we warn if you ask about a resource that we can't find), but we would still interrogate the authorization system and return the results as we do today. /kind feature /remove-kind bug
/cc
Change:
mapper, typer := f.Object() // TODO: use resource.Builder instead <del> obj, err := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> obj, err := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> NamespaceParam(cmdNamespace).RequireNamespace(). FilenameParam(filename). Do().

Discussion:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR
Change:
cat "${file}" echo <del> echo "= ${file} $(md5sum < "${file}" | awk '{print $1}')" </del> <ins> echo "= ${file} $(kube::util::md5 "${file}")" </ins> echo "================================================================================" echo done >> ${TMP_LICENSE_FILE}

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: run on macOS, all md5 hashes will be stripped from the output and the script will not fail or warn. What you expected to happen: The script should work or detect this issue and fail. Currently it silently ignores not existing on the host. We have some warning logic, but solely based on bash version, if the user upgraded their bash installation but did not install md5sum we don't warn them. How to reproduce it (as minimally and precisely as possible): run the script 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 testing /priority important-longterm /assign
cc