jiebi/CodeConvo huggingface dataset:
Change:
source := &v1.HostPathVolumeSource{ Path: "/tmp", } <del> pod := testPodWithHostVol(volumePath, source, true) </del> <ins> // we can't spawn privileged containers on Windows, nor do we need to. privileged := !framework.NodeOSDistroIs("windows") pod := testPodWithHostVol(volumePath, source, privileged) </ins> // Write the file in the subPath from container 0 container := &pod.Spec.Containers[0]

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --/sig testing /sig windows /area conformance Which jobs are failing: N/A Which test(s) are failing: [sig-storage] HostPath should support r/w [NodeConformance] [sig-storage] HostPath should support subPath [NodeConformance] Since when has it been failing: Before 2019-03-07. Since then, the Windows nodes' kubelet service has been passed the , which allows the test to pass. Testgrid link: (older than 2019-03-07) Reason for failure: The tests are trying to spawn pods with a HostPath volume ( folder has 777 file permissions by default, meaning it should pass without privileged access. The tests have turned green in the linked testgrid because the Windows Kubelet flag ` has been set to true, but it shouldn't have been necessary in the first place. Anything else we need to know:
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
Change:
e2ewebsocket "k8s.io/kubernetes/test/e2e/framework/websocket" imageutils "k8s.io/kubernetes/test/utils/image" admissionapi "k8s.io/pod-security-admission/api" <ins> "k8s.io/utils/pointer" </ins> "github.com/onsi/ginkgo" "github.com/onsi/gomega"

Discussion:
[X] test approval issue : [X] test pr : 28/07/2022 [X] two weeks soak end date : 12/07/2022 [X] test promotion pr : The endpoint as seen on the website is tested but not part of conformance. The APIsnoop query below shows that there is no conformance test for this endpoint. patchCoreV1NamespacedPodStatus Using a number of existing e2e test practices a new has been created for this pod status endpoint. The e2e logs for this test are listed below. This query shows the pod status endpoints hit within a short period of running the e2e test. If a test with these calls gets merged, test coverage will go up by 1 point. This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance /sig node
/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]:
/remove-lifecycle stale targeting this for 1.25
/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
Change:
operation := string(sample.Metric["operation_name"]) status := string(sample.Metric["status"]) statusCounts := result.statusMetrics[operation] <ins> metricPluginName := string(sample.Metric["volume_plugin"]) if len(pluginName) > 0 && pluginName != metricPluginName { continue } </ins> switch status { case "success": statusCounts.successCount = count

Discussion:
Which jobs are flaking: () () Which test(s) are flaking: Reason for failure: Timeout: Anything else we need to know: This test flaking about 10% of the time in this job. /sig storage /kind flake /priority important-soon cc
/remove-kind failing-test
/assign
I noticed one issue with the test is that it's not filtering metrics by plugin name. So it will just count the last plugin's metric. I'm not sure if the metrics collected are in any sorted order or not. If not, then when you have a suite that runs multiple plugins, then you might be pulling from the wrong metric.
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
/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
still very prevalent in sig-release dashboards
I have pushed which should hopefully fix this.
Also PR against 1.17 branch -
Change:
} return nil } <del> // isJournaldAvailable returns whether the system executing the tests uses // journald. func isJournaldAvailable() bool { _, err := exec.LookPath("journalctl") return err == nil } // readinessCheck checks whether services are ready via the supplied health // check URLs. Once there is an error in errCh, the function will stop waiting // and return the error. // TODO(random-liu): Move this to util func readinessCheck(name string, urls []string, errCh <-chan error) error { glog.Infof("Running readiness check for service %q", name) endTime := time.Now().Add(*serverStartTimeout) blockCh := make(chan error) defer close(blockCh) for endTime.After(time.Now()) { select { // We *always* want to run the health check if there is no error on the channel. // With systemd, reads from errCh report nil because cmd.Run() waits // on systemd-run, rather than the service process. systemd-run quickly // exits with status 0, causing the channel to be closed with no error. In // this case, you want to wait for the health check to complete, rather // than returning from readinessCheck as soon as the channel is closed. case err, ok := <-errCh: if ok { // The channel is not closed, this is a real error if err != nil { // If there is an error, return it return err } // If not, keep checking readiness. } else { // The channel is closed, this is only a zero value. // Replace the errCh with blockCh to avoid busy loop, // and keep checking readiness. errCh = blockCh } case <-time.After(time.Second): ready := true for _, url := range urls { resp, err := http.Head(url) if err != nil || resp.StatusCode != http.StatusOK { ready = false break } } if ready { return nil } } } return fmt.Errorf("e2e service %q readiness check timeout %v", name, *serverStartTimeout) } </del>

Discussion:
In node e2e, we have the option to keep the services running after test for further debug. However, we set to for the services, which means that once the parent exits, they will receive and exit with the parent if they don't trap the signal. With this, option will never work. If we still need this feature, we should not set if is false. /cc
We still need this feature. It helps with debugging test failures by keeping all the daemons running upon failure. , Lantao Liu wrote:
Change:
} defer newF.Close() f.Close() <del> if err := watcher.Remove(f.Name()); err != nil && !os.IsNotExist(err) { klog.ErrorS(err, "Failed to remove file watch", "path", f.Name()) } </del> f = newF <del> if err := watcher.Add(f.Name()); err != nil { return fmt.Errorf("failed to watch file %q: %v", f.Name(), err) } </del> r = bufio.NewReader(f) } // If the container exited consume data until the next EOF

Discussion:
won't output logs after kubelet rotate log filer of the container. kubectl output logs correctly after the log file is rotated. the config to . So kubelet will rotate the log soon. Build a image with this program a deploy with the previous image. the command No response <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
/area kubelet
/triage accepted /priority important-longterm
/assign since you sent a PR already
Ran into this issue!
Change:
package proxy import ( <ins> "strconv" </ins> "testing" v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/klog/v2" </ins> ) func TestNodePodCIDRHandlerAdd(t *testing.T) { <ins> oldKlogOsExit := klog.OsExit defer func() { klog.OsExit = oldKlogOsExit }() klog.OsExit = customExit </ins> tests := []struct { name            string oldNodePodCIDRs []string

Discussion:
There are some cases when kube-proxy has to exit and restart, in order to do that we panic, but this has the problem that the log output shows a literal "panic" message and engineers, support, customers and automation gets confused, thinking that is a problem when is the expected behavior. As suggested by in , we can replace by /sig network /help /kind cleanup
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : There are some cases when kube-proxy has to exit and restart, in order to do that we panic, but this has the problem that the log output shows a literal "panic" message and engineers, support, customers and automation gets confused, thinking that is a problem when is the expected behavior. /help /kind cleanup </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign I would like to raise a PR to fix this.
Change:
policies := []batch.ConcurrencyPolicy{batch.AllowConcurrent, batch.ForbidConcurrent, batch.ReplaceConcurrent} *cp = policies[c.Rand.Intn(len(policies))] }, <ins> func(p *batch.PodFailurePolicyOnPodConditionsPattern, c fuzz.Continue) { c.FuzzNoCustom(p) if p.Status == "" { p.Status = api.ConditionTrue } }, </ins> } }

Discussion:
pull-kubernetes-unit: TestRoundTripTypes Unknown No response No response /sig api-machinery
/kind bug /triage accepted
cc
cc I think fuzzing is missing a default for the newly type, so when fuzzing adds an entry, the original doesn't match the round-tripped data (which applies the API default)
/priority important-soon /remove-sig api-machinery /sig scheduling /assign
this will also need picking to release-1.25
/remove-sig scheduling /sig apps
/assign
/unassign
Change:
} func (plugin *cniNetworkPlugin) Status() error { <del> // sync network config from confDir periodically to detect network config updates plugin.syncNetworkConfig() </del> // Can't set up pods if we don't have any CNI network configs yet return plugin.checkInitialized() }

Discussion:
What happened: When Node's iops is full, the Node status becomes to be NotReady. The NotReady message is "Container runtime is not ready". After our troubleshoot, we found func in cni package costs more then 30s, then the runtime status health check is failed : What you expected to happen: Node should still be in Ready status when iops is full. Because the CNI config files does not change. How to reproduce it (as minimally and precisely as possible): Run an application to fill disk IO bandwidth, then the Node becomes to be NotReady. Anything else we need to know?: Nothing yet. Environment: Runtime is dockershim. Other environment is no need to pay attention.
/assign /sig-node
/sig node /sig network
Change:
}) ginkgo.BeforeEach(func() { <del> if err := lookEmitSignalCommand(); err != nil { e2eskipper.Skipf("skipping test because: %v", err) return } </del> ginkgo.By("Wait for the node to be ready") waitForNodeReady() })

Discussion:
xref: Graceful node shutdown test uses to invoke dbus - As per some distros, don't have installed so the test must be skipped in those environments. We should consider if we can switch to use or perhaps and fall back to to ensure the test can work across more distros.
/sig node
/sig testing
/remove-kind bug /kind feature I'm putting kind feature to signify that nothing is really broken in k8s, tests needs improvement.
/remove-sig testing This dbus command should be up to SIG node, though tentatively: /triage accepted
/area test
Do we actually have these other distros available to prevent regressions if we change that?
/assign
the change will be to replace skip logic when is missing to use an alternative way to send this. So there will be no regression on distros where it currently runs without the skip. Original bug should have a link to job that was failing
I would like to work on improving the command. Am I understanding correct here We have to change to logic where we skip to use busctl instead. Could you please give me some idea on how can we make it to use , some similar examples in the repo would be really useful.
please have a look at The issue is that the command available is too old and doesn't include .
I see, it looks like we are not just adding a condition for instead we are replacing it with . It looks you are already working on it. Please inform if I can help in anyway. Thanks for the response.
Both are possible... it was easier to get a CI signal if that was used in all cases. I might put the condition later. I am waiting for comments in the PR, but feel free to propose other solutions that might work with older systemd versions.
Change:
} for vmssName := range vmssNamesMap { <del> vmss, err := ss.GetScaleSetWithRetry(service, ss.ResourceGroup, vmssName) </del> <ins> vmss, err := ss.getVMSS(vmssName, cacheReadTypeDefault) </ins> if err != nil { return 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! If the matter is security related, please disclose it privately via --What happened: Recently we upgraded our cluster from 1.14.4 to 1.14.7. Then we started to observe tons of following errors: I guess the cause may be related to this line which was introduced recently: As we have hundreds of services with LoadBalancer type, and we also enable cluster-autoscaler, the nodes list change very often. For each service, there will be one call to GetScaleSet. The quota will be exhausted quickly. When fails, new nodes created by cluster-autoscaler will lose connectivity to load balancer. What you expected to happen: Kubernetes should not hit VMSS throttling threshold. How to reproduce it (as minimally and precisely as possible): a cluster with aks-engine. Use VMSS. 200 services with LoadBalancer type. up VMSS to 50 nodes down VMSS to 60 nodes scaling up and down VMSS Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.7 Cloud provider or hardware configuration: Azure, VMSS OS (e.g: ): Ubuntu Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure
I create a PR to mitigate the issue.
do we have a rough num about how this PR would mitigate this issue? looks like we need to cherry-pick this PR to old releases. it's better if we have a rough estimation.
The revised version of code calls instead of azure API. The cache refreshes itself every 10 min. I believe this will solve the throttling issue.
I believe we're being affected by this. Apart from getting the - when creating our to use a pre-configured Azure Public IP, the ingress appears to be getting a different IP each time
Thank you all!
The PR is merged. Does your issue remain?

pls cherry-pick that fix to old release, thanks
Cherry picked to release 1.14-1.16
I’ll retry today and let you know Wysłane z iPhone'a
Issue returned in K8S 1.15.4 Warning UpdateLoadBalancerFailed service/nginx-ingress-controller Error updating load balancer with new hosts map[<nodes names]: [EnsureHostInPool(ingress/nginx-ingress-controller): backendPoolID(/subscriptions/<subscription/resourceGroups/<rg/providers/Microsoft.Network/loadBalancers/<rg/backendAddressPools/<rg) - failed to ensure host in pool: "azure - cloud provider rate limited(read) for operation:VMSSGet", EnsureHostInPool(ingress/nginx-ingress-controller):
Change:
"//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/meta:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library",

Discussion:
What happened: Created a CRD: Created another CRD defining an overlapping type with CustomResourceDefinition: Verify both exist: Deleted the one overlapping with the in-tree CRD type: Verify only the overlapping CRD remains: and is stuck deleting: What you expected to happen: Creation and deletion of the overlapping type CRD would have no effect on the in-tree data. Anything else we need to know?: The only types in the kube-apiserver (currently) that store data under a group prefix are: APIService () CustomResourceDefinition () Custom resources () When a CRD is deleted, all instances of the type it defines are first removed. That means that defining and deleting a CustomResourceDefinition that defines an overlapping APIService or CustomResourceDefinition type will remove existing APIService or CustomResourceDefinition data. We can special-case these two resources in the CRD deletion code, but we need a more robust solution before CRD v1. /cc /sig api-machinery /priority important-soon /area custom-resources
/sub
Is anyone working on this? I'll like to take a stab at this.
Not currently, no. Great. I'd suggest discussion a potential solution here before diving into code. The two main aspects are: -time - Should we forbid creating CRDs that overlap with built-in types? -time - How do we detect a CRD overlapping with a built-in type and skip the etcd cleanup for it
I think we should forbid creating CRDs that overlap (option 1).
That can help, but is not sufficient. Imagine: n forbids creating overlapping CRDs on version n creates MyType, which is allowed because that is not a built-in type upgrades to version n+1 which adds MyType as a built-in type deletes CRD What should happen?
For that, we may need delete-time detection of overlapping types as well (option 2), which may make option 1 redundant. Do you have any advice for detecting overlapping CRDs?
for now, just delete-time detection in
Change:
<ins> [SaltStack reactor](http://docs.saltstack.com/en/latest/topics/reactor/) files, largely defining reactions to new nodes. **Ignored for GCE, which runs standalone on each machine** </ins>

Discussion:
We need to document all the configuration derived by Salt. Ideally this would be a markdown doc that we kept as live documentation within the project. The main reasons to bother: It's hard right now for anyone approaching the directory to get a big picture view of what's is going on, especially across providers. If we ever want to do something disciplined w.r.t. upgrade between (non-dev) versions, we're probably going to need a place to look for the state of the world. Decreasing the velocity with which people can add to Salt configuration will encourage people to delete more Salt configuration. cc
Change:
Volumes       []Volume      `json:"volumes"` Containers    []Container   `json:"containers"` RestartPolicy RestartPolicy `json:"restartPolicy,omitempty"` <del> // Optional: Set DNS policy.  Defaults to "ClusterFirst" </del> <ins> // Required: Set DNS policy. </ins> DNSPolicy DNSPolicy `json:"dnsPolicy"` }

Discussion:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc