jiebi/CodeConvo huggingface dataset:
Change:
} func newWatchCache( <ins> capacity int, </ins> keyFunc func(runtime.Object) (string, error), eventHandler func(*watchCacheEvent), getAttrsFunc func(runtime.Object) (labels.Set, fields.Set, error),

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /cc /priority critical-urgent /milestone v1.19
/sig api-machinery
Suspect it has to do with cc /assign (for CI signal ownership)
Seems unlikely since multiple kind e2e tests passed on the PR itself
I was thinking that as well, but I don't see any other relevant changes
Actually, I take that back. Looks like the same failure was encountered as a flake on some of the PR runs. Looking at the test, it appears to assume the resource version of the kubernetes service will always be in the watch window, which is a bad assumption. I'd expect us to fix that assumption in the test, but also make sure we didn't unintentionally shrink the watch window for resources.
/assign
Note: this also appears to be breaking
Failure seems to be timeout related as well shows the runtime ~tripled after merged
revert open in can investigate test failure and timeouts and bring the change back in
I take it back, the test tolerates an expired error explicitly.
showed 17 of the 22 runs since merged took ~1 hour. The first run after the revert at returned to less than 30 minutes for the run. Will keep an eye on that to see if subsequent runs match.
- thanks a lot for looking into it. I don't think my PR changed anything that anyone should rely on. I will take a deeper look into it and try to fix that (hopefully later this week).
contains the explanation and describes the bug (in fact this bug still exists in the codebase, that PR was only increasing the probability of this particular test hitting it)
Change:
rm "${SAR_RESULT_FILE}" SAR_RESULT_FILE="${KUBE_TEMP}/sar-result.json" <del> curl -kfsS -H "Content-Type:" --oauth2-bearer admin-token "https://localhost:${SECURE_API_PORT}/apis/authorization.k8s.io/v1/subjectaccessreviews" -XPOST -d @test/fixtures/pkg/kubectl/cmd/create/sar-v1.json > "${SAR_RESULT_FILE}" </del> <ins> curl -kfsS -H "Content-Type:" -H 'Authorization: Bearer admin-token' "https://localhost:${SECURE_API_PORT}/apis/authorization.k8s.io/v1/subjectaccessreviews" -XPOST -d @test/fixtures/pkg/kubectl/cmd/create/sar-v1.json > "${SAR_RESULT_FILE}" </ins> if grep -q '"allowed": true' "${SAR_RESULT_FILE}"; then kube::log::status ""authorization.k8s.io/subjectaccessreviews" returns as expected: $(cat "${SAR_RESULT_FILE}")" else

Discussion:
What happened: After running ./hack/update-openapi- with the latest code, api/openapi- file became empty even when no changes were made in the code. What you expected to happen: After running ./hack/update-openapi- with the latest code, api/openapi- file should not be changed when no changes were made in the code. When I tried the same thing a few week back, I didn't encounter this problem. How to reproduce it (as minimally and precisely as possible): Download the latest kubernetes/kubernetes code and run the following script to update openapi spec. api/openapi- became empty after this. Anything else we need to know?: There's a line in update-openapi- that runs a curl command . This line was changed a few days ago by this commit: PR: I checked out the commit before and ran /update-openapi- It works. is not empty any more. Is there any new setting required before running ./hack/update-openapi- now? 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
cc
Hi, thanks for the report, but it is a bit weird that I could not reproduce locally: and besides, completes successfully on my machine. Could you reproduce?
Someone else also ran into this same problem and asked a question on sig-api-machinery slack yesterday. So I'm not the only one who ran into this.
could you change the args passed to curl in to and rerun the script to see if there is any error?
since it is already late here(UTC+8), I would check this issue again tomorrow
I was the "someone else" who ran into this problem :) I changed the script to use The result: Actually, it was 403 without the "S", too, but that is visible only if curl is executed in verbose mode.
Hi, thanks for your information. Given that the apiserver returned 403, I suspect the flag passed to curl has no effect in your environment, would you mind posting the output of ? I am using curl 7.64.1: In addition, I think you could try changing the curl command in to the following: and see if the problem is solved.

I tried the following and it worked for me. is no longer empty. curl version:
Thanks for your confirmation, and I have filed to address this issue.
I can confirm, it works with the changed curl command.
/triage accepted
Change:
package e2e import ( <del> "github.com/golang/glog" </del> <ins> "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/apis/extensions" </ins> . "github.com/onsi/ginkgo" )

Discussion:
e.g. scale up if CPU usage exceeds 70% of CPU request. Subtasks: [x] Add API changes [x] Add implementation [x] Add support in kubectl to print status with cpu request utilization [x] Add e2e tests
I've sent main PR for review (). During your day/my night please look into kubectl changes and e2e tests.
Change:
// To avoid this users can: (1) wait between starting a service and starting; or (2) detect // missing service env var and exit and be restarted; or (3) use DNS instead of env vars // and keep trying to resolve the DNS name of the service (recommended). <del> serviceEnv, err := kl.getServiceEnvVarMap(pod.Namespace, *pod.Spec.EnableServiceLinks) </del> <ins> serviceEnv, err := kl.getServiceEnvVarMap(pod.Namespace, enableServiceLinks) </ins> if err != nil { return result, err }

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: Kubelet panics after registering node What you expected to happen: Kubelet should not panic How to reproduce it (as minimally and precisely as possible): Use kubelet on an ARM64 machine (i'm on Scaleway provider) Anything else we need to know?: I upgraded from 1.12.3 to 1.13.0 here is the statup log (only the end): Environment: Kubernetes version (use ): 1.13.0 Cloud provider or hardware configuration: Scaleway OS (e.g. from /etc/os-release): Debian GNU/Linux 9 (stretch) Kernel (e.g. ): 4.15.11-mainline-rev1 Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig node
a few questions: can you provide full output of , including the server version? did you upgrade kube-apiserver to 1.13.0? are you running static pod manifests on the kubelet?
hello i had rollbacked this node cannot currently no i didn't. I just upgraded on one server kube-proxy and kubelet. Kube-proxy works fine. i don't have static pods, just daemonsets on this node (metrology)
kubelet must not be newer than kube-apiserver be sure to upgrade kube-apiserver to 1.13 before upgrading kubelet
/close
Closing this issue. <detailsIn response to : /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
i understand but why not just have a proper error instead of a ugly stack trace then ? it's more proper than an unhandled error. Here it's a memory error, a memory error is a grave error.
/reopen cc for disposition
Reopened this issue. <detailsIn response to : /reopen cc for disposition 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
code in question is here: note that this is an unsupported configuration
Refer the discussion here:
Solved using 1.13.0 api server. But i really think we need to handle this more properly than a stack
Should kubelet mark the node NotReady if it sees an older apiserver?
it sounds reasonable, and if we can have a description on the node saying: not compatible can be better
Change:
// Swap is only configured if a swap cgroup controller is available and the NodeSwap feature gate is enabled. func (m *kubeGenericRuntimeManager) configureContainerSwapResources(lcr *runtimeapi.LinuxContainerResources, pod *v1.Pod, container *v1.Container) { if !swapControllerAvailable() { <del> klog.InfoS("No swap cgroup controller present", "swapBehavior", m.memorySwapBehavior, "pod", klog.KObj(pod), "containerName", container.Name) </del> return } swapConfigurationHelper := newSwapConfigurationHelper(*m.machineInfo) if m.memorySwapBehavior == kubelettypes.LimitedSwap { if !isCgroup2UnifiedMode() {

Discussion:
it still looks like we'll be logging for every container for the whole kubelet lifetime... that seems like log spam, right? Originally posted by in
We want to only log this once on kubelet startup. Spamming the logs for every container/pod is not really that useful.
/sig node
/triage accepted /priority important-longterm IIUC this is part of the KEP graduation process (otherwise I'll have probably set priority backlog)
Change:
# k8s.io/sample-apiserver => ./staging/src/k8s.io/sample-apiserver # k8s.io/sample-cli-plugin => ./staging/src/k8s.io/sample-cli-plugin # k8s.io/sample-controller => ./staging/src/k8s.io/sample-controller <del> # k8s.io/system-validators => k8s.io/system-validators v1.5.0 </del> <ins> # k8s.io/system-validators => k8s.io/system-validators v1.6.0 </ins> # k8s.io/utils => k8s.io/utils v0.0.0-20210930125809-cb0fa318a74b # modernc.org/cc => modernc.org/cc v1.0.0 # modernc.org/golex => modernc.org/golex v1.0.0

Discussion:
every k8s release, if changes are to we release a new version of the library and vendor it in this repository. TODO: [ ] wait for changes to accumulate in [ ] add new release in before the k8s 1.23 release [ ] vendor the new release in k/k (example PR: )
/sig cluster-lifecycle node /milestone v1.23 /assign
/triage accepted
/cc
Change:
- group: root - mode: 644 <ins> /etc/monit/monit_watcher.sh: file.managed: - source: salt://monit/monit_watcher.sh - user: root - group: root - mode: 755 crontab -l | { cat; echo "* * * * * /etc/monit/monit_watcher.sh 2>&1 | logger"; } | crontab -: cmd.run: - unless: crontab -l | grep "* * * * * /etc/monit/monit_watcher.sh 2>&1 | logger" </ins> monit-service: service: - running

Discussion:
The cluster I created on Friday (at head) was running over the weekend, and when I tried to talk to it this morning, I couldn't. SSH'ing into the master, I couldn't hit and Docker isn't running and neither is monit so what happened to monit? found in monit. My questions are: "Why?" and "Should we try to debug this further?" pointed out that a possible preventative measure is to have a cron job running that kicks monit if it's dead. I left the cluster running, so if anyone would like me to run commands or would like to dig in more, please let me know.
I haven't thought much about this, but it may be related to Docker being slow at restarting? As a side note, it seems like pretty poor design that monit dies if it fails to restart something.
Could you please take a look at this? Thanks!
you started the cluster on Friday, could you connect to apiserver using kubectl ? you see any errors in the file ?
cc
, the cluster functioned on Friday; I was running tests against it. (If you look at the monit log I pasted above, it appears it was functioning for quite a while.) don't see any errors there, but I can dump it here if it would help (it's quite long, obviously).
out-of-memory errors seen/logged around the time when monit failed to fork a child process. seems to consume 400m of memory. not sure why it is so high the fork did fail because of insufficient memory, but this is a guess and no logs to substantiate it
Just as an explicit followup, there were at least 8 out-of-memory errors that happened on that instance (a master) from the logs in —is this normal? I can provide several different logs or VM access for interested parties...
Regardless of the cause of the problem (which I agree would be interesting to discover) it seems like we need a cron job or something to make sure that monit is always running. can you look into how we can babysit our babysitter?
I will take a look this one today since there are several ones related to each other: , , ...
Change:
} func newClaim(t testsuites.StorageClassTest, ns, suffix string) *v1.PersistentVolumeClaim { <del> return getClaim(t.ClaimSize, ns) </del> <ins> claim := getClaim(t.ClaimSize, ns) if t.VolumeMode == v1.PersistentVolumeBlock { blockVolumeMode := v1.PersistentVolumeBlock claim.Spec.VolumeMode = &blockVolumeMode } return claim </ins> } func getDefaultPluginName() 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 --What happened: I created a block EBS volume using dynamic provisioning. Then I resized the volume from 10GB to 20 GB. Both PV and block volume reflects the change, but the PVC's capacity is still 10GB. This could be caused by in-tree resize put the PVC condition under state, but no one is acting on the condition since it is block volume: /cc /sig storage What you expected to happen: PVC's capacity should be updated to 20GB How to reproduce it (as minimally and precisely as possible): Easy to reproduce using following specs: StorageClass: Claim: Pod: Anything else we need to know?: This will affect whether CSI migration should handle migration scenario for block volume resizing. Environment: Kubernetes version (use ):1.13 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: kops Network plugin and version (if this is a network-related bug): Others:
/sig aws
/assign
Change:
"//vendor/github.com/onsi/ginkgo:go_default_library", "//vendor/github.com/onsi/gomega:go_default_library", "//vendor/github.com/pkg/errors:go_default_library", <ins> "//vendor/k8s.io/utils/pointer:go_default_library", </ins> ], )

Discussion:
We need to add e2e that verifies volume permissions in pod with different values of fsGroupChangePolicy. /sig storage
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
Change:
backendPods = createBackendPodsOrFail(clusters, nsName, FederatedServicePodName) <del> service = createLBServiceOrFail(f.FederationClientset, nsName, FederatedServiceName) </del> <ins> service = createLBServiceOrFail(f.FederationClientset, nsName, FederatedServiceName, clusters) </ins> obj, err := scheme.Scheme.DeepCopy(service) // Cloning shouldn't fail. On the off-chance it does, we // should shallow copy service to serviceShard before

Discussion:
In order to support running tests in parallel, we randomized NodePort selection. There appears to be some evidence that this is not sufficient and is causing e2e test flakes: https://k8s-
Hi, As a need contributor, I'm interesting of solving this issue. I already check the current code, and propose to retry the service creation until success or all possible ports (between FederatedSvcNodePortFirst and FederatedSvcNodePortLast) have been tried. If this approach is fine for you, I can submit a PR soon.
How do you plan to check if the NodePorts are available? In our presubmit test environment, tests run across many instances of federation control planes in parallel, but share the same underlying clusters. So this approach might be viable depending on how and where you plan to check for these used NodePorts.
my approach for getting an available port is a "Dummy" approach: create a list of possible available port, get one of them randomly, then try to create the Service. If Service creation failed. try to use another possible available port, until service creation success or all possible available ports have been tested.
Sounds reasonable to me. Go for it. A couple of caveats: need to create a real list, you could just use the range boundaries. careful about service creation failure. You need to check if the service shard creation failed in the underlying clusters and rollback all those shards before retrying.
thanks for the caveats, I will do soon a PR.
Hi, what is the state of this issue? Is working in this issues with the others issues related to e2e tests?
has a PR to fix this issue -
Change:
visible at runtime in the container. release: v1.9 file: test/e2e/common/node/downwardapi.go <ins> - testname: Ephemeral Container Creation codename: '[sig-node] Ephemeral Containers [NodeConformance] will start an ephemeral container in an existing pod [Conformance]' description: Adding an ephemeral container to pod.spec MUST result in the container running. release: "1.25" file: test/e2e/common/node/ephemeral_containers.go </ins> - testname: init-container-starts-app-restartalways-pod codename: '[sig-node] InitContainer [NodeConformance] should invoke init containers on a RestartAlways pod [Conformance]'

Discussion:
Issue tracking the addition of Ephemeral Containers to the . Exercising ephemeral containers in the node conformance test is required for
/assign /sig node /priority important-longterm /triage accepted
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /assign /sig node /priority important/long-term /triage accepted 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
/priority important-longterm
Change:
package metrics import ( <ins> "sync" "sync/atomic" </ins> "github.com/blang/semver" "github.com/prometheus/client_golang/prometheus" dto "github.com/prometheus/client_model/go" apimachineryversion "k8s.io/apimachinery/pkg/version" ) <ins> var ( showHiddenOnce sync.Once showHidden     atomic.Value ) // SetShowHidden will enable showing hidden metrics. This will no-opt // after the initial call func SetShowHidden() { showHiddenOnce.Do(func() { showHidden.Store(true) }) } // ShouldShowHidden returns whether showing hidden deprecated metrics // is enabled. While the primary usecase for this is internal (to determine // registration behavior) this can also be used to introspect func ShouldShowHidden() bool { return showHidden.Load() != nil && showHidden.Load().(bool) } </ins> // Registerable is an interface for a collector metric which we // will register with KubeRegistry. type Registerable interface {

Discussion:
The metrics framework requires the ability to optionally display hidden (deprecated) metrics. A boolean needs to be piped through the registry (possibly at initialization or possibly set later) which then needs to be passed to the Create function so that we can determine whether we need to actually create the metric. /sig instrumentation
Change:
func (c *configFactory) getPluginArgs() (*PluginFactoryArgs, error) { return &PluginFactoryArgs{ <del> PodLister:                      c.podLister, </del> <ins> PodLister:                      c.schedulerCache, </ins> ServiceLister:                  c.serviceLister, ControllerLister:               c.controllerLister, ReplicaSetLister:               c.replicaSetLister,

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Consider use schedulerCache to replace fields in PluginFactoryArgs ref: /assign
/sig scheduling /priority backlog
Change:
ret=1 fi <del> if ! _out="$(diff -Naupr -x "BUILD" -x "AUTHORS*" -x "CONTRIBUTORS*" vendor ${_kubetmp}/vendor)"; then </del> <ins> if ! _out="$(diff -Naupr -x "BUILD" -x "OWNERS" -x "AUTHORS*" -x "CONTRIBUTORS*" vendor ${_kubetmp}/vendor)"; then </ins> echo "Your vendored results are different:" echo "${_out}" echo "Godeps Verify failed."

Discussion:
/assign /cc Please ensure that every sub directory of / contains an owners file. The following sub directories do not define them: The result of this is that any PR which changes anything in api, Godeps, staging, vendor, etc will always get assigned to one of you for both the review and approval.
I recall someone also mentioning that certain files or dirs may not need approvers files. If that would help, we can add that functionality (i've already started the work)
staging and api should be easy to find owners for. may have ideas for translations. The big one is Godeps, third_party, vendor. Those are just grunt work. And figuring out criteria for approving is hard as they are a lot of code and it is unclear that things are tested well or automatically. (I'm thinking things like libraries for accessing cloud APIs). Having a dedicated team/process there might help.
I'll open some proposals for staging and API.
Godep in particular needs to be watched for things like licenses, which I have mostly been doing.
Thanks Clayton for the staging and api additions! How about if we pick two of you at random and shove them in as owners for each of the remaining directories?
What's left: translations: the kubectl specific translations is being handled by sig-cli, but the rest of the files like README and test have been handled and approved mostly by thirdparty: this is a tricky mix of stuff like forked code.. mostly handled by the likes of or for approvals. Godep/vendor: These could probably be solved by having a process to follow, and then delegating to a team in OWNERSALIASES for both folders.
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
Still relevant. /remove-lifecycle stale