jiebi/CodeConvo huggingface dataset:
Change:
// ClientConfig contains all essential information to create an Azure client. type ClientConfig struct { <ins> CloudName               string </ins> Location                string SubscriptionID          string ResourceManagerEndpoint string

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : PR() already proves that old api-version on Azure stack works on global Azure too, we could support azure stack in azure cloud provider lib, and then make sure following components works in Azure stack: CSI drivers: azure disk, azure file CCM Since it's mainly api-version change, we could also add e2e tests against global Azure too. Why is this needed: /assign /priority important-soon /sig cloud-provider /area provider/azure
there is blocking issue here(also need azure stack supports latest data model struct): just making the change in interfaces and not go-sdk but facing this error, since we don't have a switch inside go-sdk, we only do switch in azure cloud provider lib,
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:
Expression: "object.spec.replicas", }). WithVariable(admissionregistrationv1beta1.Variable{ <del> Name:       "replicasReminder", // a bit artificial but good for testing purpose Expression: "variables.replicas % 2", </del> <ins> Name:       "oddReplicas", Expression: "variables.replicas % 2 == 1", </ins> }). WithValidation(admissionregistrationv1beta1.Validation{ <del> Expression: "variables.replicas > 1 && variables.replicasReminder == 1", </del> <ins> Expression: "variables.replicas > 1", }). WithValidation(admissionregistrationv1beta1.Validation{ Expression: "variables.oddReplicas", </ins> }). Build() policy, err := client.AdmissionregistrationV1beta1().ValidatingAdmissionPolicies().Create(ctx, policy, metav1.CreateOptions{})

Discussion:
Variables field is to ValidatingAdmissionPolicy in 1.28. Currently the usage of variables would expect a operator associated. e.g. (thanks to Mariam Fahmy for raising the issue) Above will fail with error: Meanwhile the will pass. The reason is when variables be evaluated to non dyn type(like bool or string), it will require special handling(like casting) since we use dyn type everywhere. It might confuse user.
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
/triage accepted /sig api-machinery /cc
Tests I'd expect to see verify this behavior: PASS: A variable is of type bool, an expression returns the variable PASS: A variable is of type string, a messageExpression returns the variable PASS: A variable is of type dyn, at runtime the dyn is a bool, an expression returns the variable PASS: A variable is of typedyn, at runtime the dyn is a string, an messageExpression returns the variable PASS: A expression is of type dyn, at runtime the dyn is of type bool PASS: A messageExpression is of type dyn, at runtime the dyn is of type string COMPILE ERROR: A variable is of type bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should resultsin a compile error COMPILE ERROR: A variable is of type string, an expression tries to perform a non-string (e.g. less than) operation on the variable, this should result in a compile error RUNTIME ERROR: A variable is of type dyn, at runtime the dyn is a bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should result in a runtime error I'd also expect to see some cases covering variables of other types (maps, lists, duration, quantity, ...) to make sure we're over-fitting for bool and string.
/retitle ValidatingAdmissionPolicy: variable expression type not recognized as return type in expression that evaluates the variable
/assign
Change:
s.readCalled = true b := []byte(s.data) n := copy(p, b) <ins> // Indicate we returned all the data, and have no more data (EOF) // Returning an EOF here will cause the port forwarder to immediately terminate, which is correct when we have no more data to send </ins> return n, io.EOF }

Discussion:
ok 1.520s coverage: 25.5% of statements I0414 23:19:35. ] Forwarding from 5000 -5000 W0414 23:19:35. ] Unable to listen on port {5000 5000}: listen tcp 127.0.0.1:5000: bind: address already in use I0414 23:19:35. ] Forwarding from 6000 -6000 I0414 23:19:35. ] Handling connection for 5000 --- FAIL: TestForwardPorts (0.22s) 2: expected to read '1234', got '' FAIL coverage: 83.3% of statements FAIL 0.677s
It looks like the crux is this: ] Unable to listen on port {5000 5000}: listen tcp 127.0.0.1:5000: bind: address already in use listen often needs a retry after a recent close, to account for TIME_WAIT state of the port. But that's pure speculation on my part. We need to repro and fix.
http://hea- is perhaps a better link.
I'll have a go at it in the next few days if nobody else picks it up before me.
There were two issues... one was multiple test cases reusing the same port and deferring the close until the end of the function, not the end of the loop... that was fixed in The other issue was with the fake stream returning an EOF on a Write(), fixed in
Change:
// +optional ResourceVersion string `json:"resourceVersion,omitempty" protobuf:"bytes,4,opt,name=resourceVersion"` // Timeout for the list/watch call. <ins> // This limits the duration of the call, regardless of any activity or inactivity. </ins> // +optional TimeoutSeconds *int64 `json:"timeoutSeconds,omitempty" protobuf:"varint,5,opt,name=timeoutSeconds"`

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: Watches done with the field of set to some value T end after T regardless of whether there has been any activity in the meantime. What you expected to happen: I expected the watch to end when no events have been delivered in the last T. In ordinary usage, a "timeout" is something that happens if there has been no activity for the specified length of time. How to reproduce it (as minimally and precisely as possible): Create a configmap named in namespace . Then in one shell thrash it periodically like this: Observe that it proceeds to update the configmap every 7 seconds or so. In another shell do a watch with a timeout; observe that it ends even though the thrashing continues. Anything else we need to know?: Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.4+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-21T17:22:25Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}Cloud provider or hardware configuration: local hardware OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS Kernel (e.g. ): Linux n17s2ctrl 4.4.0-34-generic -Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: local Others:
I am told the observed behavior is the intended behavior, the problem here is that the field name and comment are misleading.
/sig api-machinery
It's a timeout on the request lifetime, not an inactivity timeout
The inactivity condition is implied in ordinary usage of the word "timeout". A word like "lifetime", "duration", or "time limit" would be a better description of the existing behavior. I do not propose changing the field name for this, that would be more work than it is worth. I propose updating the commentary on that field to make its meaning clear. BTW, what exactly is this field's meaning to a list operation?
Change:
spec: containers: - name: kibana-logging <del> image: docker.elastic.co/kibana/kibana-oss:7.1.1 </del> <ins> image: docker.elastic.co/kibana/kibana-oss:7.2.0 </ins> resources: # need more cpu upon initialization, therefore burstable class limits:

Discussion:
What happened: On latest fluentd-elasticsearch, the elasticsearch replicas seems failed to form a valid cluster with the service discovery helper written in golang. What you expected to happen: Successfully boot up an elasticsearch cluster I guess. How to reproduce it (as minimally and precisely as possible): Just use the yamls in and the elasticsearch-logging pods will keep spamming warning messages. I think thats because options are deprecated in elasticsearch 7.x.x Anything else we need to know?: IMHO I think thats all. Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig instrumentation
Thanks
Change:
if o.Attach { if remove { <del> defer o.removeCreatedObjects(f, createdObjects) </del> <ins> defer func() { if err := o.removeCreatedObjects(f, createdObjects); err != nil { fmt.Fprintf(o.ErrOut, "Delete failed: %vn", err) } }() </ins> } opts := &attach.AttachOptions{

Discussion:
The command provides a flag but this doesn't do anything. most likely the flag shouldn't exist. I have no idea how kustomize could be useful here to start a single pod. This creates a pod, and shows that is ignored: No response <details</details<detailsAzure, K3OS</details<detailsOSX 11.6.1 (Big Sur) </detailsNo response No response No response
/sig cli
This comes from the inclusion of DeleteFlags: brings in FilenameFlags: has Kustomize, resulting in the flag: I suspect there are many flags from DeleteFlags that don't really apply to . : Not sure what this would do : seems to be ignored and : doesn't seem to be used : doesn't seem to be used : also probably doesn't apply There might be others as well...
It seems to delete object which created by command.
I agree, As far as I can see, , and have this deleteFlags exposure.
/assign
/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
/triage accepted
Change:
return "", false, err } for _, name := range pods { <del> if strings.Contains(name, networkContainerName+"--"+manifest.Id+"--") { </del> <ins> if strings.Contains(name, containerNamePrefix+"--"+networkContainerName+"--"+manifest.Id+"--") { </ins> return name, true, nil } }

Discussion:
release-master-blocking Conformance-GCE-master-kubetest2Kubernetes e2e suite.[It] [sig-network] Services should be able to change the type from ExternalName to ClusterIP [Conformance] ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test 07-11 15:51 EEST No response /sig cloud-provider 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
I remember some timeout has changed with ginkgo2 and something moved from 24hours to 1 hours, or something like that, is it possible that this is the problem here, in this job?
The Grinko timeout change could also be the root problem with this job:
hmm, we have to revisit the flags
hmm, this seems correct
that was a good observations, seems that job is failing because gathering the logs takes too much time !
there is no timeout set in the kubetest2 command here (not sure if this would be the place to set a timeout)
it seems kubetest has to be migrated to ginkgov2 it should use this as basis I'm on vacation this week, can somebody take over and open the issue and patch kubetest2?
looks like this file needs to get updated: add line 72:
oh, you already commented this :D
I will have a look later
Related: umbrella issue:
last testgrid run passed :)
Change:
"description": "CustomResourceConversion describes how to convert different versions of a CR.", "properties": { "strategy": { <del> "description": "strategy specifies how custom resources are converted between versions. Allowed values are: - `None`: The converter only change the apiVersion and would not touch any other field in the custom resource. - `Webhook`: API Server will call to an external webhook to do the conversion. Additional informationn  is needed for this option. This requires spec.preserveUnknownFields to be false, and spec.conversion.webhook to be set.", </del> <ins> "description": "strategy specifies how custom resources are converted between versions. Allowed values are: - `"None"`: The converter only change the apiVersion and would not touch any other field in the custom resource. - `"Webhook"`: API Server will call to an external webhook to do the conversion. Additional informationn  is needed for this option. This requires spec.preserveUnknownFields to be false, and spec.conversion.webhook to be set.", </ins> "type": "string" }, "webhook": { "$ref": "#/definitions/io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1.WebhookConversion", <del> "description": "webhook describes how to call the conversion webhook. Required when `strategy` is set to `Webhook`." </del> <ins> "description": "webhook describes how to call the conversion webhook. Required when `strategy` is set to `"Webhook"`." </ins> } }, "required": [

Discussion:
Currently we have inconsistency in most of the API where the field name should be used in description so the generated docs match the API fields people actually set. A linter could be for checking To avoid confusing users
/good-first-issue
/triage accepted
/assign
Hey can you provide some more information for this issue
are you still working on this?
Hey feel free to take it. I am unassigning myself
/triage needs-information /remove-good-first-issue
/sig api-machinery
Change:
srcs = ["testfiles.go"], importpath = "k8s.io/kubernetes/test/e2e/framework/testfiles", visibility = ["//visibility:public"], <del> deps = ["//vendor/github.com/onsi/ginkgo:go_default_library"], </del> <ins> deps = ["//test/e2e/framework/log:go_default_library"], </ins> ) filegroup(

Discussion:
/help /kind cleanup /area e2e-testing-framework mini guide: make sure you have signed the CNCF clone kubernetes;/kubernetes search for ginkgo.Fail calls under test/e2e/framework e.g. replace them with this that was in this PR: send a PR for kubernetes/kubernetes
/remove-kind feature /area e2e-test-framework
/sig testing
I will take this.
thank you! Please feel free to ping #testing-commons in the Kubernetes slack if you have any questions :smiley: /cc
/remove-help
/assign
Change:
} } <ins> // runStaticPodTest is disabled until #6651 is resolved. </ins> func runStaticPodTest(c *client.Client, configFilePath string) { var testCases = []struct { desc         string

Discussion:
Probably not the same as ? To for triage
Shouldn't this fixed by ?
this has nothing to do with . kubelet is trying to create the mirror pod over and over again because it still hasn't observed the mirror pod from watch. It is probably the same as # .
I thought they might be different because this one has a bunch of "failed creating ... already exists" messages in it, but doesn't.
It is essentially the same problem -- the watch was delayed so kubelet kept seeing the old snapshot of the pods where the mirror didn't exist. That's why it's flaky and only happens on shippable (which I suspect has poorer performance) :( This becomes worse every time a new test is . I think we need to limit the number of concurrent tests in
limits the number of concurrent tests on travis/shippable to 4. Let's see if this helps reduce the timeout flakes.
Another example:
Here is yet another example: Retitled the issue since limiting the concurrent tests doesn't work. It could be that the server is heavily loaded and the test timed out, or there was a delay/drop in kubelet's pod watch stream.
Now example:
If, for whatever reason, a watch update for pod creation is dropped, kubelet would need to wait until re-listing to notice that. This would certainly cause the test to time out. would it be useful to shorten the re-listing interval for tests like this?
I am not quite sure how this works--let's chat about it tomorrow?
From , we can see that kubelet was lightly loaded as the update channel was mostly empty while waiting. This corroborates the theory that watch might be at fault.
cc: quinton-hoole
The WIP reflector benchmark () may shed some light on this issue once it's integrated with the continuous e2e performance suite. I will keep this issue open for now to gather more data (since this is not reproducible locally at all), and to see if there are other potential causes.
The PR above disables the static pod test temporarily so that we can track down the root cause without spamming people with the failures. Note that other tests in the same file () may still trigger the flaky failure, though less frequently.
Can this be closed yet?
No, integration test is still flaky. See for example.

Many tests in rely on checking the pod status with a preset timeout. I disabled one test which failed most often, but other tests still fail from time to time.
The issue has been inactive for months, and there have not been any new reports. Closing.
Change:
// UnmountDevice unmounts the volume on the node func (d *azureDiskDetacher) UnmountDevice(deviceMountPath string) error { <ins> if runtime.GOOS == "windows" { // Flush data cache for windows because it does not do so automatically during unmount device exec := d.plugin.host.GetExec(d.plugin.GetPluginName()) err := util.WriteVolumeCache(deviceMountPath, exec) if err != nil { return err } } </ins> err := mount.CleanupMountPoint(deviceMountPath, d.plugin.host.GetMounter(d.plugin.GetPluginName()), false) if err == nil { klog.V(2).Infof("azureDisk - Device %s was unmounted", deviceMountPath)

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: pull-kubernetes-e2e-azure-disk-windows Which test(s) are flaking: [Fail] Dynamic Provisioning [single-az] [It] should create a statefulset object, write and read to it, delete the pod and write and read to it again [] [] [Windows] Testgrid link: Reason for failure: Unknown Anything else we need to know: Unexpected error: <*errors.errorString | 0xc0007c26a0: { s: "Failed to find "hello worldrnhello worldrn", last result: "x00x00x00x00x00x00x00x00x00x00x00x00x00hello worldrn"", } Failed to find "hello world hello world ", last result: " hello world " occurred
/sig cloud-provider /area provider/azure
Ref: I will try to solve it.
Ref:
/assign
The PR kubernetes-sigs/azuredisk-csi-driver should fix the error. Let's observe this test case for a period of time. When it is stable, could close the issue.
Change:
QOSReserved: {Default: false, PreRelease: featuregate.Alpha}, <del> ReadWriteOncePod: {Default: false, PreRelease: featuregate.Alpha}, </del> <ins> ReadWriteOncePod: {Default: true, PreRelease: featuregate.Beta}, </ins> RecoverVolumeExpansionFailure: {Default: false, PreRelease: featuregate.Alpha},

Discussion:
For 1.27 we should graduate the ReadWriteOncePod feature to beta. This is needed to rollout the feature to GA. In beta this feature will support preemption of pods using PVCs. See:
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 storage /sig scheduling
Change:
} e.recordToSink(event, clock.RealClock{}) } <del> stopWatcher := e.StartEventWatcher(eventHandler) </del> <ins> stopWatcher, err := e.StartEventWatcher(eventHandler) if err != nil { return err } </ins> go func() { <-stopCh stopWatcher() }() <ins> return nil </ins> } // StartRecordingToSink starts sending events received from the specified eventBroadcaster to the given sink. func (e *eventBroadcasterImpl) StartRecordingToSink(stopCh <-chan struct{}) { go wait.Until(e.refreshExistingEventSeries, refreshTime, stopCh) go wait.Until(e.finishSeries, finishTime, stopCh) <del> e.startRecordingEvents(stopCh) </del> <ins> err := e.startRecordingEvents(stopCh) if err != nil { klog.Errorf("unexpected type, expected eventsv1.Event") return } </ins> } type eventBroadcasterAdapterImpl struct {

Discussion:
Follow-up cleanup work for: Most of the information about this issue can be found in , where the work merged with a to change the function signature of to return a func() as well as an error. This issue will help to track that. All TODOs introduced in are resolved. N/A N/A <detailsN/A </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority low 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
/cc /triage accepted
/priority important-longterm
/assign
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