jiebi/CodeConvo huggingface dataset:
Change:
backoffManager wait.BackoffManager // initConnBackoffManager manages backoff the initial connection with the Watch call of ListAndWatch. initConnBackoffManager wait.BackoffManager <ins> // MaxInternalErrorRetryDuration defines how long we should retry internal errors returned by watch. MaxInternalErrorRetryDuration time.Duration </ins> resyncPeriod time.Duration // ShouldResync is invoked periodically and whenever it returns `true` the Store's Resync operation is invoked

Discussion:
When etcd is unable to elect leader for 3 election cycles, etcd returns "no leader" error through watches. This can be seen in api-server logs as . Also, when apiserver receives this error, it terminates all watchers: . In large clusters, this can destabilize master, as all these watchers need to be recreated almost at the same time, overwhelming api-server quite often. I propose adding new api-server flag that allows to specify timeout, during which we are retrying to reestablish apiserver <-etcd watches, without terminating all api-server watchers. If we are unable to reestablish watches within this specified timeout, we start terminating all watchers. Losing etcd leader for ~2-3s does not destabilize api-server. Trigger prolonged reelection of etcd leader. No response Observed in all kubernetes versions 1.19-1.24 N/A <details</details<details</details<details</details<details</details
/sig scalability /sig api-machinery /priority important-soon
/wg reliability
/assign
/triage accepted
indeed, this is a source of instability. Is this coming from ?
I believe it's coming from this change. As I mentioned, the idea to mitigate it is to add some parameter that will allow us to ignore this error coming from etcd for specific duration without terminating all watchers, for example 10s be default.
With this comment thread in mind: It would probably be cleaner to allow for simply setting the "timeout" as part of WithRequireLeader option (instead of using the constant of 3). But that would require etcd changes, including the API and we want to workaround that in much smaller timeframe. But a comment about how to make that cleaner with some additional context from here would help.
Change:
-o -wholename '*/Godeps/*'  -o -wholename '*/codecgen-*-1234.generated.go'  ) -prune  <del> ) -name '*.generated.go')) </del> <ins> ) -name '*.generated.go' | sort -r)) </ins> # Register function to be called on EXIT to remove codecgen # binary and also to touch the files that should be regenerated

Discussion:
See, e.g. This seems to be blocking multiple PRs from even being tested.
Looking.
I think I figured it out. The order of generation matters. The verify script subtly breaks that by renaming and checking the files one at a time. The update script deletes everything and then recreates them.
I have a fix. Will send a PR shortly.
Change:
glog.Errorf("unexpected copy error: %v", err) return } <ins> var watchEvent watch.Event </ins> switch { case curObjPasses && !oldObjPasses: <del> c.result <- watch.Event{Type: watch.Added, Object: object} </del> <ins> watchEvent = watch.Event{Type: watch.Added, Object: object} </ins> case curObjPasses && oldObjPasses: <del> c.result <- watch.Event{Type: watch.Modified, Object: object} </del> <ins> watchEvent = watch.Event{Type: watch.Modified, Object: object} </ins> case !curObjPasses && oldObjPasses: <del> c.result <- watch.Event{Type: watch.Deleted, Object: object} </del> <ins> watchEvent = watch.Event{Type: watch.Deleted, Object: object} } select { case c.result <- watchEvent: // don't block on c.result if c.done is closed case <-c.done: </ins> } }

Discussion:
We noticed many goroutines stalled at in a large cluster (~200 nodes, ~1100 pods). It's because if the WatchServer timeout when the channel is full, will be blocked on the write to the even though is , because WatchServer stops consuming the channel after the timeout.
Great finding - thanks for debugging
Change:
&api.NodeDaemonEndpoints{ KubeletEndpoint: api.DaemonEndpoint{Port: int(kc.Port)}, }, <ins> kc.OOMAdjuster, </ins> ) if err != nil { return nil, nil, err

Discussion:
The type has a field called to indicate that a container must run as non-root user. The description for this field includes the sentence , which would mean that setting the field to or to (unset) have the same effect: However, the PodSecurityPolicy provider implementation handles the (unset) case differently, and thus does differentiate between unset or values: The API type documentation should be updated to clarify this behaviour and reflect the actual PodSecurityPolicy implementation. /sig node
Thanks for reporting this issue. I think that would be best able to assist with this. /sig auth /remove-sig node
The pod documentation is correct. If the field is not set or is false, the enforcement is not performed by the kubelet. However, podsecuritypolicy with a runasuser strategy of mustrunasnonroot will force a pod that has not specified a runAsNonRoot setting or a runAsUser uid to runAsNonRoot: true The documentation on the MustRunAsNonRoot strategy of podsecuritypolicy should clarify the mutation behavior of the PSP /remove-kind bug /kind documentation
Can I take this issue?
^ this is something that can be changed.
Here's a proposed change to the documentation in : Is this sufficient to solve this issue? If so, should I submit a PR there?
I'd change that to to be a little more complete.
/assign See PR for docs at
GitHub didn't allow me to assign the following users: josiahbjorgaard. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign See PR for docs at 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 would have saved me some battling today! I couldn't work out why my pod wasn't selecting my run-as-root pod security policy and ignoring my restricted pod security policy - I didn't realise I had to explicitly set to get the correct PSP to match (I thought the restrictive PSP would reject the pod and then the run-as-root PSP would match, not that the restrictive PSP would mutate the PodSpec)~ It would have had I read the actual docs better sigh.
Change:
AssumeFunc: func(pod *v1.Pod) { gotAssumedPod = pod }, <ins> IsAssumedPodFunc: func(pod *v1.Pod) bool { if pod == nil || gotAssumedPod == nil { return false } return pod.UID == gotAssumedPod.UID }, </ins> } s := &Scheduler{

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Similar problem as , howerver in our case, pod's annotation was updated at scheduling cycle, so it had not been assumed when its annotation was updated. We also need to deal with this case. Detailed steps: a pod . tried to schedule the pod. Then it was prediated by a filter plugin that we write. This plugin modified the pod's annotation to record something. Because pod's annotation changed, scheduuler received a pod update event, and put the pod to the schedule queue again. scheduled the pod successfully for this schedule cycle. tried to schedule the updated pod again(it was put to the schedule queue at step 2). If the pod was scheduled sucessfully, we would see the error log() in scheduler. If scheduler failed to schedue the pod, scheduler would send a failed scheduler event to pod. They are both confusing because the pod had already been successfully. ! Why is this needed: It will be better to handle pod annotation updates during scheduling more gracefully. /kind cleanup /sig scheduling /assign
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : <!-- Please only use this template for submitting enhancement requests --1. Created a pod . Scheduler tried to schedule the pod. Then it was prediated by a filter plugin that we write. This plugin modified the pod's annotation to record something. Because pod's annotation changed, scheduuler received a pod update event, and put the pod to the schedule queue again. Scheduler scheduled the pod successfully for this schedule cycle. Scheduler tried to schedule the updated pod again(it was put to the schedule queue at step 2). If the pod was scheduled sucessfully, we would see the error log() in scheduler. If scheduler failed to schedue the pod, scheduler would send a failed scheduler event to pod. They are both confusing because the pod had already been successfully. /sig scheduler /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
Change:
}, { "ImportPath": "gopkg.in/gcfg.v1", <del> "Comment": "v1.0.0", </del> "Rev": "083575c3955c85df16fe9590cceab64d03f5eb6e" }, { "ImportPath": "gopkg.in/gcfg.v1/scanner", <del> "Comment": "v1.0.0", </del> "Rev": "083575c3955c85df16fe9590cceab64d03f5eb6e" }, { "ImportPath": "gopkg.in/gcfg.v1/token", <del> "Comment": "v1.0.0", </del> "Rev": "083575c3955c85df16fe9590cceab64d03f5eb6e" }, { "ImportPath": "gopkg.in/gcfg.v1/types", <del> "Comment": "v1.0.0", </del> "Rev": "083575c3955c85df16fe9590cceab64d03f5eb6e" }, { "ImportPath": "gopkg.in/inf.v0", <del> "Comment": "v0.9.0", </del> "Rev": "3887ee99ecf07df5b447e9b00d9c0b2adaa9f3e4" }, {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug report Kubernetes version (use ): Environment: Cloud provider or hardware configuration: vsphere OS (e.g. from /etc/os-release):Kernel (e.g. ): 4.9.24-coreos Install tools: Others: What happened: After bringing a cluster up, there are no container metrics in the kubelet at /metrics What you expected to happen: I expect to see the metrics, but there are none How to reproduce it (as minimally and precisely as possible): Anything else we need to know: If I try and access the metrics in cAdvisor directly on port 4194 instead of on port then I see the following type of error for all of the metrics:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig node
This appears to be a v1.7 issue. If I run 1.6.6 I get these metrics. Seems like something has happened in 1.7. I'm running the 1.7 beta because I need nodePort for cni, so now I'm stuck.
Can you triage the issue since?
cc/
Can you help verifying is this is a new regression introduced in 1.7 cadvisor through node-e2e? Thanks!
I've tried this on both cos and cvm in 1.7 cluster, and no container metrics show up. However, I created a 1.6.4 GKE cluster, and container metrics are there. This is a regression in 1.7. Will figure out what is wrong here.
Here is a corresponding cadvisor issue
Even the user still can get the container metrics / stats from kubelet /summary api (recommended way), but since this is a regression introduced in 1.7 release, and we aren't dropping prometheus support, let's fix this for 1.7. Thanks!
Fixed in Will close this issue after building new cadvisor release and cherrypick into 1.7
Thanks for the quick find everyone! I'll be happy to give this a go on the next release!

I'm still facing this same issue. My kubernetes cluster is deployed with kubeadm on Centos 7. I run a k8S v1.8.1 cluster. When I try to fetch containers metrics this way: http://localhost:8001/api/v1/proxy/nodes/node1:0/metrics http://localhost:8001/api/v1/proxy/nodes/node1:/metrics http://localhost:8001/api/v1/proxy/nodes/node1:/metrics I find no metrics. kubelet is started with . If I start kubelet with . metrics are available through .
Change:
gvr("flowcontrol.apiserver.k8s.io", "v1beta2", "flowschemas"): { Stub:             `{"metadata": {"name": "fs-1"}, "spec": {"priorityLevelConfiguration": {"name": "name1"}}}`, ExpectedEtcdPath: "/registry/flowschemas/fs-1", <ins> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta3", "FlowSchema"), </ins> }, // --

Discussion:
adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/cc
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Change:
"k8s.io/kubernetes/pkg/util/node" ) <del> const loadBalancerWidth = 16 </del> <ins> const ( loadBalancerWidth = 16 // LabelNodeRoleMaster specifies that a node is a master // It's copied over to here until it's merged in core: https://github.com/kubernetes/kubernetes/pull/39112 LabelNodeRoleMaster = "node-role.kubernetes.io/master" // NodeLabelRole specifies the role of a node NodeLabelRole = "kubernetes.io/role" // NodeLabelKubeadmAlphaRole is a label that kubeadm applies to a Node as a hint that it has a particular purpose. // Use of NodeLabelRole is preferred. NodeLabelKubeadmAlphaRole = "kubeadm.alpha.kubernetes.io/role" ) </ins> // AddHandlers adds print handlers for default Kubernetes types dealing with internal versions. // TODO: handle errors from Handler

Discussion:
/kind bug What happened: doesn't show role Workaround: What you expected to happen: According to and How to reproduce it (as minimally and precisely as possible): I just deployed a multi master kubernetes environment with kops: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS Install tools: kops, terraform
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig cli
I don't think this is a bug. The node role label is not used by kubeadm anymore. Related codes have been changed in by
Hi Thanks for the quick reply I'm actually using the as you can see in the workaround above. I'm not using kubeadm role label.
Your favorite topic came up again. Hi I do think this is a bug. As said, kubectl shouldn't show anything based on the old kubeadm master label, but it should probably on the label, but absolutely on the label. cc as you have opinions on this as well cc
Change:
<del> // +build linux </del> /* Copyright 2017 The Kubernetes Authors.

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Currently, IPVS proxier only runs in linux platfrom. What you expected to happen: Run IPVS proxier UTs everywhere, including !linux platfrom, which will help a lot when developing in windows platfrom. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig network
/area kube-proxy
Change:
"strings" "testing" <del> "k8s.io/component-base/metrics/legacyregistry" </del> <ins> "k8s.io/component-base/metrics" </ins> "k8s.io/component-base/metrics/testutil" )

Discussion:
Change encryption config controller reload metrics to be consistent with other places (Authn, Authz) xref: Combine and into a single metric with with an enum value of and . /sig auth /triage accepted
cc
We probably should keep the existing metrics for some time to allow folks to migrate to the new one.
Ah I was thinking about this as well! Looking at "may be deleted at any time", I was leaning towards just removing it. If the common approach is to keep it for a release before removing, we could do that. I believe we can set a for the 2 metrics we want to remove.
I don't have a good sense of metrics stability because they tend to stay alpha forever and folks don't go back to update them. Since the associated feature set is GA, I think we should be conservative with the changes we make. Perhaps SIG instrumentation folks can provide some guidance here?
As part of the PR, I was going to ask when is the right time to graduate these metrics do you have thoughts on to take while deleting an alpha metric metrics should be graduated from alpha to beta and stable?
Change:
return &Client{client}, nil } <ins> // MatchesServerVersion queries the server to compares the build version // (git hash) of the client with the server's build version. It returns an error // if it failed to contact the server or if the versions are not an exact match. </ins> func MatchesServerVersion(c *Config) error { client, err := New(c) if err != nil {

Discussion:
This seems like a bug to me No output, and command exits success... wat. Have to explicitly pass to see expected output. If the client version is greater the server version, it should be making requests based on the server's newest accepted apiversion.
cc
Change:
package main import ( <ins> "errors" </ins> goflag "flag" "fmt" "math/rand"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: when i run hollow-node deploymenthollow-proxy will cause panic. hollow-node deployment is as follows: hollow-proxy container logs: I1012 12:37:13. 7 ] syncProxyRules took 622.278µs I1012 12:37:13. 7 asmamd64.s:573] Shutting down service config controller E1012 12:37:13.

7 ] Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference) /usr/local/go/src/runtime/asmamd64.s:573 /usr/local/go/src/runtime/asmamd64.s:2361 panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x2c68ad9] goroutine 74 [running]: (0x0, 0x0, 0x0) +0x107 panic(0x32dc9e0, 0x5c20d20) +0x229 (FakeExec).LookPath(0xc420ad4450, 0x3ac6dba, 0x9, 0xc4208c51d0, 0x0, 0xc4200a4800, 0x4e7e83) +0x39 (0x3e3c000, 0xc420ad4450, 0xc4208c51d0, 0x5, 0x5, 0x5, 0x5) +0x5e (0x3e3c000, 0xc420ad4450, 0xc420768c70, 0xc, 0x3abdd6d, 0x3, 0x0, 0x0) +0x17d (Proxier).syncProxyRules(0xc420d8fe40) +0xb643 (Proxier).OnServiceSynced(0xc420d8fe40) +0x62 (ServiceConfig).Run(0xc420ad5080, 0xc4200b62a0) +0x183 created by (*ProxyServer).Run +0x283 What you expected to happen: How to reproduce it (as minimally and precisely as possible): boot up hollow-proxy container with "--use-real-proxier=true" 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: I found that in "kubemark/hollow-" we init a 'FakeExec' struct, but we don't init LookPathFunc in 'FakeExec' struct. So, execer.LookPathFunc is a vild pointer, so it cause panic.
/sig Testing
maybe we need init:
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
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 I met this issue as well.
/sig scalability
Change:
} func getTestPod(critical bool, name string, resources v1.ResourceRequirements) *v1.Pod { <ins> value := scheduling.SystemCriticalPriority </ins> pod := &v1.Pod{ TypeMeta: metav1.TypeMeta{ Kind:       "Pod",

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
} func (g *glusterFSDriver) CreateDriver() { <del> // Reset config. It might have been modified by a previous CreateVolume call. g.driverInfo.Config.ServerConfig = nil </del> } func (g *glusterFSDriver) CleanupDriver() {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce/gke multizone/regional jobs Which test(s) are failing: Only PD tests Since when has it been failing: Around 12/21 with the 16:49 run Testgrid link: https://k8s- Reason for failure: TBD Anything else we need to know: <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
The runs started flaking after merged. cc Here's one failing run: Pod pod-subpath-test-gcepd-dynamicpv-pfsm failed to schedule because of conflicting node selectors: We shouldn't need to set the node selector for PD tests using PVs.
The PR broke the subpath test because the modification to the config struct embedded in the driver info now persists across tests: A quick fix would be to reset that field in CreateDriver. The long-term fix is the change discussed in My preference is to do the quick fix now, then either merge or close PRs in this order: (needs a decision about logging of tests that aren't getting defined, see ) a future PR for What I'd like to avoid is having to rebase PR on top of the long-term solution for issue - that'll be lots of code conflicts.
/assign PR is here: PR
Change:
} loadBalancerIP := apiService.Spec.LoadBalancerIP <del> if loadBalancerIP != "" { </del> <ins> if loadBalancerIP != "" && internalAnnotation { </ins> createOpts.Address = loadBalancerIP }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Currently openstack cloud provider just support for specifying internal LoadBalancerIP. I think that is unreasonable, actually user just use a floating ip to access a LoadBalancer service. So it is necessary to spport for specifying external LoadBalancerIP. What you expected to happen: Support for specifying external LoadBalancerIP on openstack Anything else we need to know?: Currently LoadBalancerIP can be specified in service.Spec.LoadBalancerIP, we can add annotation to distinguish between internal and external.
/sig openstack /assign I'd like to work for it.