jiebi/CodeConvo huggingface dataset:
Code change:
// for the iSCSI connection. dirs2, err := io.ReadDir(sessionPath) if err != nil { <del> return nil, err </del> <ins> klog.Infof("Failed to process session %s, assuming this session is unavailable: %s", sessionName, err) continue </ins> } for _, dir2 := range dirs2 { // Skip over files that aren't the connection

Related discussion:
text: If one target in multipath volume gets down and a pod that uses the volume is deleted and quickly recreated (e.g. by a Deployment), the new pod never starts. How to reproduce it (as minimally and precisely as possible): Deployment with single replica with one multipath iSCSI volume one target (e.g. switch the machine off). Multipath will mark appropriate path as failed: the deployment pod. will quickly start a new pod for the Deployment. new pod will be (or ) forever, What happened: Kubelet tries to WaitForAttach / SetUp volume for the new pod. The volume is still attached. Kubelet goes through all targets and tries to find out if it's logged in or not. Eventually it tries to read of the failed path and that returns error: What you expected to happen: Kubelet assumes that the path is failed / not logged in and tries to recover it. If it fails it continues with multipath with 2 available devices and 1 failed one. IMO, simple instead of will do its job just fine. /assign /sig storage cc for iSCSI expertise
Fix:
Code change:
return nil } <ins> // hasServedCRDVersion returns true if the given version is in the list of CRD's versions and the Served flag is set. func hasServedCRDVersion(spec *apiextensions.CustomResourceDefinitionSpec, version string) bool { for _, v := range spec.Versions { if v.Name == version { return v.Served } } return false } </ins>

Related discussion:
text: Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestWebhookConverterWithDefaulting /assign /priority important-soon /area custom-resources /sig api-machinery /kind flake /milestone v1.16
/cc
several of the webhook converter tests have similar flakes. it looks like the wait for storage version to become effective times out occasionally Rare flakes seen in all of these tests: TestWebhookConverterWithWatchCache/nontrivial-converter TestWebhookConverterWithWatchCache/metadata-mutating-converter TestWebhookConverterWithDefaulting/metadata-mutating-converter TestWebhookConverterWithWatchCache/noop-converter TestWebhookConverterWithDefaulting/empty-response TestWebhookConverterWithoutWatchCache/nontrivial-converter/check-2 TestWebhookConverterWithoutWatchCache/noop-converter/check-0/v1beta2 TestWebhookConverterWithoutWatchCache/nontrivial-converter/check-0/v1beta2
cc
Yikes, I’ll sort it out.
iiuc sending an empty patch gets short-circuited and doesn't bump CR generation, even if the storage version gets changed, which means we do not re-write to etcd and go through the encoding path this would be racing and doing noop's if the first pass of didn't get the expected storage version I will send a fix to make the patch do actual mutation
It doesn't bump generation, but the bytes to persist in etcd would still be different if the storage version had changed, so they should persist. You can verify that by changing the storage version on a CRD yourself, do an empty patch, and see if the resourceVersion changes.
you're right. Generation is for non-metadata change only, and the RV changes. I queried etcd locally and the apiVersion did change for an empty patch (sidetracking: another observation is after changing the storage version (say v1 -v2; noop convertor), empty-patching v2 endpoint would bump generation, while empty-patching v1 endpoint wouldn't)
another theory: our cached storage strategy could be stale if the CRD informer merges multiple events together (e.g. the informer does a re-list).
Code change:
return nil } <ins> // hasServedCRDVersion returns true if the given version is in the list of CRD's versions and the Served flag is set. func hasServedCRDVersion(spec *apiextensions.CustomResourceDefinitionSpec, version string) bool { for _, v := range spec.Versions { if v.Name == version { return v.Served } } return false } </ins>

Related discussion:
text: Two scenarios: -create-update events merged into an update event: strategy with UID:a was created on demand for CRD Foo Foo was deleted and recreated strategy with UID:b was created on demand for the new Foo new Foo got updated (e.g. switching storage version) the strategy with UID:b is supposed to be deleted and , to reflect the last update. But if the CRD informer merges the delete-create-update events into , the strategy with UID:a will be deleted, but the strategy with UID:b won't. -update events merged into a create event: strategy with UID:a was created on demand for CRD Foo Foo was updated (e.g. switching storage version) the strategy with UID:a is supposed to be deleted and , to reflect the last update. But if the CRD informer merges the create-update events into , the strategy with UID:a won't be deleted (as we don't react on create events). another race found in , which could happen in a single update.
I think I :
Code change:
"time" utilnet "k8s.io/apimachinery/pkg/util/net" <ins> utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/client-go/tools/cache"

Related discussion:
text: [x] two weeks soak end date : 18 March 2021 According to this APIsnoop query, there are still some remaining RESOURCENAME endpoints which are untested. with this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Note: Community feedback for the e2e test has lead to a number of improvements including extending the test coverage to all outstanding endpoints listed above. As each endpoint is tested a &rsquo;watch&rsquo; confirms that the result is valid before testing the next endpoint. readCoreV1NamespacedServiceStatus (get /status) patchCoreV1NamespacedServiceStatus (patch /status) replaceCoreV1NamespacedServiceStatus (update /status) patchCoreV1NamespacedService Create a Service with a static label Patch the Service with a new label and updated data Get the Service to ensure it&rsquo;s patched Upate the Service with a new label and updated data Get the Service to ensure it&rsquo;s updated Delete Namespaced Service via a Collection with a LabelSelector This query by apisnoop shows that all outstanding endpoints as list at the start of this document have been hit by the e2e test. Note that the results do include other service endpoints that have been addressed in other conformance tests. If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
Can you please review the proposed test and advise if we could go ahead with a PR
/assign
It looks like it's patching metadata and spec but not status?
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've been retesting this mock test and apisnoop does log as been hit. From my testing below it looks like the patchStatus is working as expected or have I missed something?
Code change:
"time" utilnet "k8s.io/apimachinery/pkg/util/net" <ins> utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/client-go/tools/cache"

Related discussion:
text: Using the following code before the patch request Gives this response Then after running the patch ServiceStatus Then running The response shows the patched changes.
During the Conformance Meeting on 12th of January 2021, reviewed approach with Clayton, and we will start on the test PR this week!
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
/triage accepted
Code change:
// MinionList is a list of minions. type MinionList struct { JSONBase `json:",inline" yaml:",inline"` <del> Items    []Minion `json:"minions,omitempty" yaml:"minions,omitempty"` </del> <ins> Items    []Minion `json:"items,omitempty" yaml:"items,omitempty"` </ins> } // Binding is written by a scheduler to cause a pod to be bound to a host.

Related discussion:
text: should have the JSON attribute name "items", not "minions"
Doh! Fix now and break clients?
Define Items and Minions and use Convertors to resolve it?
Sure. I'll make a fix.
Code change:
} func IsMirrorPod(pod *api.Pod) bool { <del> if value, ok := pod.Annotations[kubetypes.ConfigMirrorAnnotationKey]; !ok { return false } else { return value == kubetypes.MirrorType } </del> <ins> _, ok := pod.Annotations[kubetypes.ConfigMirrorAnnotationKey] return ok } func getHashFromMirrorPod(pod *api.Pod) (string, bool) { hash, ok := pod.Annotations[kubetypes.ConfigMirrorAnnotationKey] return hash, ok } func getPodHash(pod *api.Pod) string { // The annotation exists for all static pods. return pod.Annotations[kubetypes.ConfigHashAnnotationKey] </ins> }

Related discussion:
text: See for more context. Currently, kubelet compares the spec of a mirror pod (created via apiserver) with that of a static pod (config stored as a file) to decide whether the two are considered identical. If they differ, kubelet would delete the mirror pod and re-create it with the correct spec. Due to the fact that apiserver may set default values for some fields in the spec of the mirror pod, the specs could deviate undesirably. To avoid problems like this, we can store the config of a static pod as an annotation in the mirror pod, and compare the static pod with the annotation.
Would a hash of the config be sufficient if we're only going to compare? The whole spec would generally be more useful, but I wonder if that is too much data to put in an annotation.
This seems totally reasonable to me, but I'm still desperately curious why you can't just bypass defaulting when you generate mirror pod from static pod? (i.e. just use the static pod's configuration verbatim)
It's not kubelet who applies the default values here. The admission plugin was only run at the apiserver, and to bypass that, you have to ask apiserver to treat mirror pods differently and potentially at multiple places.
On May 22, 2015 10:38 AM, "Yu-Ju Hong" wrote: Understood, but is it really multiple places? If so then I agree it's a bad idea. Otherwise it might be worth considering as an alternative.
It's untenable for Kubelet to assume to know/circumvent all fields that will be set by other entities: admission control, defaulting, late initialization, auto-something, whatever. It needs to obey the same rules as other clients.
I don't understand why you would ever want to apply any of the things you mentioned to static pods. Static pods should be copied verbatim into the mirror pods, right? That's what I'm proposing.
What if the master is updated before the kubelet, and the master adds a new API field with a default value?
That case should be discussed in
I agree that mirror pod should reflect the true status of the static pod running on the node, and no default values should be set in this case.
Code change:
} func IsMirrorPod(pod *api.Pod) bool { <del> if value, ok := pod.Annotations[kubetypes.ConfigMirrorAnnotationKey]; !ok { return false } else { return value == kubetypes.MirrorType } </del> <ins> _, ok := pod.Annotations[kubetypes.ConfigMirrorAnnotationKey] return ok } func getHashFromMirrorPod(pod *api.Pod) (string, bool) { hash, ok := pod.Annotations[kubetypes.ConfigMirrorAnnotationKey] return hash, ok } func getPodHash(pod *api.Pod) string { // The annotation exists for all static pods. return pod.Annotations[kubetypes.ConfigHashAnnotationKey] </ins> }

Related discussion:
text: However, I think it'd be harder to implement this way since, as stated above, that there are many things to circumvent in the apiserver itself. It could also be harder to keep this special case from being broken by a yet another new feature/plugin. Keeping the hash of the config in the annotation seems like a good compromise even though it may not reflect the true status 100% accurately. I think this is acceptable. What do you think?
Sure, if you think the annotation approach is easier, I would go with that. I guess in the case Brian mentoined (master adds a new API field with a default value), you would not update the mirror pod, because the static pod definition has not changed?
Yes, a hash would be sufficient.
It shouldn't be necessary to update the mirror pod in the case that a new default field was updated, because that field should be populated automatically by the apiserver on decode from etcd.
We should fix this so we don't have this problem again in 1.2.
Code change:
tester(unconfined) }) <del> By("Running a CAP_SYS_ADMIN pod", func() { </del> <ins> By("Running a SYS_ADMIN pod", func() { </ins> sysadmin := restrictedPod(f, "sysadmin") sysadmin.Spec.Containers[0].SecurityContext.Capabilities = &v1.Capabilities{ <del> Add: []v1.Capability{"CAP_SYS_ADMIN"}, </del> <ins> Add: []v1.Capability{"SYS_ADMIN"}, </ins> } sysadmin.Spec.Containers[0].SecurityContext.AllowPrivilegeEscalation = nil tester(sysadmin)

Related discussion:
text: The pod security policy capability test is using wrong CAP format with prefix. In our document, we explicitly say: It fails for cri-containerd. I'll find out why it doesn't fail for Docker, maybe docker has handled it. But we should fix the test anyway.
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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 change:
// General settings. fs.StringVar(&s.ContainerRuntime, "container-runtime", s.ContainerRuntime, "The container runtime to use. Possible values: 'docker', 'remote'.") fs.StringVar(&s.RuntimeCgroups, "runtime-cgroups", s.RuntimeCgroups, "Optional absolute name of cgroups to create and run the runtime in.") <del> _ = fs.Bool("redirect-container-streaming", false, "[REMOVED]") // TODO: Delete in v1.22 fs.MarkDeprecated("redirect-container-streaming", "Container streaming redirection has been removed from the kubelet as of v1.20, and this flag will be removed in v1.22. For more details, see http://git.k8s.io/enhancements/keps/sig-node/20191205-container-streaming-requests.md") </del> // Docker-specific settings. fs.StringVar(&s.DockershimRootDirectory, "experimental-dockershim-root-directory", s.DockershimRootDirectory, "Path to the dockershim root directory.")

Related discussion:
text: [ ] OWNERSALIASES:581: # conformance aliases [x] // More info: ~~ [x] // See [x] fs.MarkDeprecated("redirect-container-streaming", "Container streaming redirection has been removed from the kubelet as of v1.20, and this flag will be removed in v1.22. For more details, see ") [x] // More info: [x] // More info: ~~ [x] [x] [x] CHANGELOG/CHANGELOG-[scalability validation report]: ~~ [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [x] ALPHA stability level ) [ ] link: [ ] link: Some needs to be regenerated
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
/help
/kind documentation
/remove-kind bug
/good-first-issue
/assign I shall fix .
/assign i'm working in
i have create a pr for
i see , you need
/assign fixing
/assign
/assign CHANGELOG/CHANGELOG-
/assign CHANGELOG/CHANGELOG- Edit : Link is already resolved, unassigning
/assign CHANGELOG/CHANGELOG-
/assign ,111
Sorry, already assigned
/assign i will take
/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
  is merged. Most KEP links are fixed. You may scan it again. fixed most of them.
/sig architecture
/assign I will work on and
/remove-help
Code change:
concurrencyLimit:            6, evalDuration:                time.Second * 20, expectedFair:                []bool{true}, <del> expectedFairnessMargin:      []float64{0.15}, </del> <ins> expectedFairnessMargin:      []float64{0.155}, </ins> expectAllRequests:           true, evalInqueueMetrics:          true, evalExecutingMetrics:        true,

Related discussion:
text: pull-kubernetes-unit TestDifferentWidths As far back as triage board history shows No response /sig api-machinery
/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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active 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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available .
Code change:
concurrencyLimit:            6, evalDuration:                time.Second * 20, expectedFair:                []bool{true}, <del> expectedFairnessMargin:      []float64{0.15}, </del> <ins> expectedFairnessMargin:      []float64{0.155}, </ins> expectAllRequests:           true, evalInqueueMetrics:          true, evalExecutingMetrics:        true,

Related discussion:
text: If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Running into this one a fair bit in my PRs, opened as a possible fix
/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
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues 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: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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 I got this in --
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
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues 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: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .
Code change:
concurrencyLimit:            6, evalDuration:                time.Second * 20, expectedFair:                []bool{true}, <del> expectedFairnessMargin:      []float64{0.15}, </del> <ins> expectedFairnessMargin:      []float64{0.155}, </ins> expectAllRequests:           true, evalInqueueMetrics:          true, evalExecutingMetrics:        true,

Related discussion:
text: /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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 Got this in
Reopened this issue. <detailsIn response to : /reopen Got this in </details
/remove-lifecycle rotten