jiebi/CodeConvo huggingface dataset:
Change:
Containers: []v1.Container{ { Name:    "pv-recycler", <del> Image:   "gcr.io/google_containers/busybox", </del> <ins> Image:   "busybox:latest", </ins> Command: []string{"/bin/sh"}, Args:    []string{"-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z "$(ls -A /scrub)" || exit 1"}, VolumeMounts: []v1.VolumeMount{

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: Use the above two files create one PV and PVC, then delete the PVC, the PV will become failed but not released. The busybox recycler never succeed for power. /sig storage What you expected to happen: 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:
/kind bug The solution is like image, we should enable end user can customize the recycle image. It will not only fail on power but also s390x, so we should make sure the recycle image can be customized. /cc any comments for the solution?
Dup of . This issue can be closed, since we've already got flags and for this.
Just search and , but found that they are only defined as flags and no one is using them, can you please help double check, am I missing anything?
Also the claiming that it does not support multi node cluster, this is not acceptable.
: please see Please try them out, if they do not work then we can see how to get those fixed (and avoid adding yet another config option)
Yes, since we may only got only one (maybe setup several for LB, but they can be considered identical), it is necessary for running on non-amd64 platorm to have the right busybox image, which is exactly trying to fix. I've reopened . , so the simplest way is just replacing to . And docker will help us choose the right os-arch busybox image. What's remaining that mentioned is whether we should adding a new flag to add registry url for such recycler pod image exclusively.
Thanks and I also found an example here We do not need the registry url as the pod template was customized by the end user and they can define where got the recycler images. The problem is that the customized recycler will not work in mixed environments as only one recycle pod can be specified in controller manager, so +1 to , we should make support multi arch.

not quite catch your idea of how to support, can you please provide some dummy yaml templates and some configuration files to explain? Thanks!
Actually all the , including , has been updated along with . This means will help us make the decision to choose the right busybox image. You can have a try to on different architectures, like and . A can help you and multi-arch docker images. With this support, on different os/arch can pull the right image with a same busybox image. As long as we have used such multi-arch images, those flags can work in a multi-node cluster.
Change:
// Value of Filesystem is implied when not included in claim spec. // +optional VolumeMode *PersistentVolumeMode `json:"volumeMode,omitempty" protobuf:"bytes,6,opt,name=volumeMode,casttype=PersistentVolumeMode"` <del> // This field requires the VolumeSnapshotDataSource alpha feature gate to be // enabled and currently VolumeSnapshot is the only supported data source. // If the provisioner can support VolumeSnapshot data source, it will create // a new volume and data will be restored to the volume at the same time. // If the provisioner does not support VolumeSnapshot data source, volume will </del> <ins> // This field can be used to specify either: // * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot - Beta) // * An existing PVC (PersistentVolumeClaim) // In order to use VolumeSnapshot object types, the appropriate feature gate // must be enabled (VolumeSnapshotDataSource) // If the provisioner can support the specified data source, it will create // a new volume based on the contents of the specified PVC or Snapshot. // If the provisioner does not support the specified data source, the volume will </ins> // not be created and the failure will be reported as an event. // In the future, we plan to support more data source types and the behavior // of the provisioner may change.

Discussion:
/kind feature /sig storage /sig api PVC Data Sources have been in beta since 1.16 and should be ready to be promoted to GA in the 1.18 release. KEP:
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /kind feature /sig storage /sig api 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:
- getResourceAPIGroup - listStorageV1CSINode - listStorageV1VolumeAttachment <del> - patchCoreV1NamespacedPersistentVolumeClaimStatus - patchCoreV1PersistentVolumeStatus </del> - patchStorageV1CSINode - patchStorageV1VolumeAttachment - patchStorageV1VolumeAttachmentStatus <del> - readCoreV1NamespacedPersistentVolumeClaimStatus - readCoreV1PersistentVolumeStatus </del> - readStorageV1CSINode - readStorageV1VolumeAttachment - readStorageV1VolumeAttachmentStatus <del> - replaceCoreV1NamespacedPersistentVolumeClaimStatus - replaceCoreV1PersistentVolumeStatus </del> - replaceStorageV1CSINode - replaceStorageV1VolumeAttachment - replaceStorageV1VolumeAttachmentStatus

Discussion:
[x] test approval issue : [x] test pr : [x] Flake [x] two weeks soak end date : 31 Oct 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 6 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 6 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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:
expectDelete: false, }, { <del> description:  "DS-managed terminated pod", node:         node, expected:     cordonedNode, pods:         []corev1.Pod{dsTerminatedPod}, rcs:          []corev1.ReplicationController{rc}, args:         []string{"node"}, expectFatal:  false, expectDelete: true, </del> <ins> description:           "DS-managed terminated pod", node:                  node, expected:              cordonedNode, pods:                  []corev1.Pod{dsTerminatedPod}, rcs:                   []corev1.ReplicationController{rc}, args:                  []string{"node"}, expectFatal:           false, expectDelete:          true, expectOutputToContain: "node/node drained", </ins> }, { description:  "orphaned DS-managed pod",

Discussion:
When draining a node, using kubectl drain [NODE], the output resembles this: Expected output should indicate that the node was drained, for example: kubectl drain [NODE] No response <details</details<detailsCan reproduce locally using and printing the output </details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted
Change:
} }) <del> By("not removing non-exist images [Conformance]", func() { </del> <ins> By("not removing non-exist images", func() { </ins> for _, conformImage := range conformImages { err := conformImage.Remove() Expect(err).Should(HaveOccurred())

Discussion:
As of now node e2e requires all the tests to pass. There are tests like the container conformance tests which have been flaky in the past - , , We need ability to mark certain tests as flaky and not run them as part of merge queue.
Ginkgo flags makes it possible to skip tests. We can use a prefix to not run flaky tests in our existing jenkins CIs.
Closing via
Change:
case deletePet: err = petManager.Delete(pet) } <del> if err != nil { </del> <ins> switch err.(type) { case errUnhealthyPet: // We are not passing this error up, but we don't increment numPets if we encounter it, // since numPets directly translates to petset.status.replicas continue case nil: continue default: </ins> it.errs = append(it.errs, err) } }

Discussion:
Is this a request for help? Nope What keywords did you search in Kubernetes issues before filing this one? petset replicas current desired Is this a BUG REPORT or FEATURE REQUEST? BUG Kubernetes version Client Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: 24 cores, 64 GB RAM OS Arch Linux Kernel (e.g. ): Linux hostname 4.4.13-1-lts SMP Wed Jun 8 16:44:31 CEST 2016 x86_64 GNU/Linux Install tools: local-cluster- Others: What happened: While creating PetSet based on this tutorial: first PetSet pod was stuck in pending state due to lack of PersistentVolumes in cluster. When getting the petset info via I expected to see "CURRENT" set to 1, while the kubectl output was as follows: While clearly shows that only one pod is created: In json and yaml output, status.replicas value was also 2. What you expected to happen: I expected that CURRENT value shown by kubectl would be due to only one pod being created. How to reproduce it (as minimally and precisely as possible): Create via on empty cluster and run and . Anything else do we need to know: Nope
CURRENT is the number of pods that have been created, not that they are READY. See for example the latest api change for replica sets where we exactly for this reason. All controllers (petsets, daemonsets, deployments, etc.) should have ReadyReplicas cc:
See also
I guess it doesn't work anyway, since only one pod was created for this PetSet, but the CURRENT says that 2 were created. I will change bug description then.

Hmm, the idea is to sync every pet periodically, but only create them one at a time. The logic that counts status.replicas is wrong. This counter shouldn't be incremented in the case where we didn't update/sync or create a pet: Today we do increment it all pet creation is blocked on the first pet becoming unhealthy. Should be an easy fix if anyone wants to jump in ( fyi) otherwise I'll get to it once 1.4 is out.
I can try to fix it if that's OK. Thanks for the pointer to the source code!
Please do, co-assigned
Change:
"--cluster-cidr=$(${kube_env}['CLUSTER_IP_RANGE'])", "--hostname-override=${instance_name}" ) $kubeproxy_args = ${default_kubeproxy_args} + ${kubeproxy_args} Log-Output "Final kubeproxy_args: ${kubeproxy_args}"

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: There's a race condition between starting Windows service and when the VMs network is actually available to communicate with the VM's metadata server. If the service starts first and cannot communicate with the metadata server or start talking to the stackdriver logging service it'll crash and not resume because the service is not configured to restart on failure. Typically a is used for a service like this but Windows does not support privileged containers so a standard Windows Service is used. What you expected to happen: If the service fails to start it should be automatically be restarted. How to reproduce it (as minimally and precisely as possible): This is a flaky issue but a way to repro this is to effectively by RDP'ing into the node and running: Anything else we need to know?: Environment: Kubernetes version (use ): v1.16 and onward Cloud provider or hardware configuration: GCE OS (e.g: ): Windows Kernel (e.g. ): Windows (any version) Install tools: cluster/gce/windows/README-GCE-Windows-kube- Network plugin and version (if this is a network-related bug): Others:
/sig windows
/assign jeremyedwards
GitHub didn't allow me to assign the following users: jeremyedwards. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign jeremyedwards 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:
cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "k8s.io/kubernetes/pkg/kubectl/resource" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/util/strategicpatch" </ins> ) // AnnotateOptions have the data required to perform the annotate operation

Discussion:
and work in this pattern: first issuing a "GET" to the API server to retrieve the latest object, then adding the label/annotation to the object, and finally issuing an "PUT" with the modified object. The request will fail if the object stored in the server has been updated between the "GET" and "PUT", even if the update has no conflict with the label/annotate request. In such cases, instead of returning an error, should retry without disturbing the end user. There are two ways to implement this: in kubectl: simply retry the label/annotate process several times if the server rejected the request because the object has been updated. The only exception is when the is set, then kubectl shouldn't retry. the strategicMergePatch instead of calling Update at client-side. PATCH is more robust because PATCH does the "get, modify, update" in the server-side, so there is less chance to have a conflict, and PATCH will retry at the server-side (see ). We need to make some adaptions though: kubectl annotate/label has the , when it's false, kubectl should retrieve the latest object to confirm there is no existing annotation/label of the same key, and then proceed with issuing the patch. if the is set, [UPDATE:] we just need to specify the resourVersion in the patch, then it will be treated as a precondition by the UpdateResource() handler in the API server. I plan to take the first approach as an immediate fix.
Immediate need is to fix the flaky e2e test AIUI.
e2e? do we have an issue out there? is an immediate fix to the flake in test-
If this is for 1.1, it needs to be P0 at this point. Should it be?
Fwiw I use annotations both from cmd line as an admin and from scripts, to experiment with loadbalancer settings. In the case of the former, I've never really had a collision, and in the case of the latter my scripts know how to retry like we retry all other updates.
Thank you When used in scripts, the annotate and label commands have collisions frequently, e.g. in the test-, see . IMO, we shouldn't require users to retry in their scripts if we know there is a simple way to avoid the collisions. Anyway, and are sent to fix this.
Change:
package nodelifecycle import ( <ins> "fmt" "sync" "time" "github.com/golang/glog" </ins> "k8s.io/api/core/v1" apiequality "k8s.io/apimachinery/pkg/api/equality" apierrors "k8s.io/apimachinery/pkg/api/errors"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug Description: If TaintNodesByCondition enabled, we should disable and predicates in scheduler. In TaintNodeByCondition, we will handle those conditions: , , and ; NetworkUnavailable checking is removed by predicates, but and not (no predicate for ). /cc
/sig scheduling /sig node
/assign
Change:
"//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", "//vendor/k8s.io/klog:go_default_library", <ins> "//vendor/k8s.io/utils/exec:go_default_library", </ins> "//vendor/k8s.io/utils/keymutex:go_default_library", "//vendor/k8s.io/utils/strings:go_default_library", ],

Discussion:
What happened: In order to communicate with the target, the iscsi plugin creates a new iface. If for some reason an iface with the same name already exists in the node, this command will re-create it and no error will be reported. However, if the iface already exists and is being used by a session, this command will fail and report the error code 15 (). That's because it can't re-create the iface while it's in use by a session. What you expected to happen: The plugin could go ahead and use the existing iface instead of failing. How to reproduce it (as minimally and precisely as possible): pod1 pod2 Here, will re-use the session/iface from the step above. pod1 At this point, k8s will try to delete the session/iface used by pv1. However, it'll fail because the session is currently in use by pv2. pod1 Here the pod's status will be stuck at : Templates used: Anything else we need to know?: problem happens when a custom initiator is used, and it was reported to me that it's necessary in some set-ups in order to "restrict access to LUNs of the storage". to reproduce manually (assuming there's a session using the iface): /sig storage /CC
/assign
is this related to cc
If iface is reused, wouldn't it try to delete it once last volume (from kubelet perspective) is detached?
No
Change:
- apiGroups: - "" resources: <ins> - nodes verbs: - get - list - apiGroups: - "" resources: </ins> - events verbs: - watch

Discussion:
Is this a request for help? : No What keywords did you search in Kubernetes issues before filing this one? : PVC, Openstack, RBAC Is this a BUG REPORT or FEATURE REQUEST? : BUG REPORT Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-19T18:44:27Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.4.666+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-05-30T09:26:07Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: Openstack OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-47-generic Install tools: kubeadm Others: N/A What happened: kube-controller-manager could not list nodes becase of missing permission for persistent-volume-binder service account. What you expected to happen: persistent-volume-binder service account should be able to list nodes. How to reproduce it (as minimally and precisely as possible): bootstrap a cluster with RBAC and try to create cinder PVC on openstack. Anything else we need to know:
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 .
/sig auth
Change:
clock clock.Clock } <del> func (recorder *recorderImpl) generateEvent(object runtime.Object, annotations map[string]string, timestamp metav1.Time, eventtype, reason, message string) { </del> <ins> func (recorder *recorderImpl) generateEvent(object runtime.Object, annotations map[string]string, eventtype, reason, message string) { </ins> ref, err := ref.GetReference(recorder.scheme, object) if err != nil { klog.Errorf("Could not construct reference to: '%#v' due to: '%v'. Will not report event: '%v' '%v' '%v'", object, err, eventtype, reason, message)

Discussion:
is defined here but never used. As this is an unexported method it doesn't affect anyone, just a small point of confusion for the reader. /sig api-machinery /kind bug
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted </details
/triage accepted removing triage since the PR seem to be fixing the issue /assign Please close when merged! thank you
Change:
f = framework.NewDefaultFramework("daemonsets") image := "gcr.io/google_containers/serve_hostname:v1.4" <del> redisImage := "gcr.io/google_containers/redis:e2e" </del> <ins> redisImage := "gcr.io/k8s-testimages/redis:e2e" </ins> dsName := "daemon-set" var ns string

Discussion:
Kubernetes version (use ): master What happened: Pulling the redis image takes a while, like 30 seconds in GCE. This might be leading to periodic timeouts in tests like . What you expected to happen: Tests shouldn't depend on large images that take a potentially long time to pull. proposed fix to reduce flakiness we can increase the replica count on this test to 2 or make the redis image we use smaller (or not use redis at all and just use a simpler smaller image)
cc (considering this as a bug since we shouldnt need a 500MG image just to test kubectl :))
This should be as simple as changing the current to use alpine and install redis, instead of basing it off debian, installing gcc, and compiling redis from source :-) The image should be ~10MB.
Change:
config.DeleteNodePortService() ginkgo.By(fmt.Sprintf("dialing(udp) %v (node) --> %v:%v (nodeIP) and getting ZERO host endpoints", config.NodeIP, config.NodeIP, config.NodeUDPPort)) <del> err = config.DialFromNode("udp", config.NodeIP, config.NodeUDPPort, config.MaxTries, config.MaxTries, sets.NewString()) </del> <ins> // #106770 MaxTries can be very large on large clusters, with the risk that a new NodePort is created by another test and start to answer traffic. // Since we only want to assert that traffic is not being forwarded anymore and the retry timeout is 2 seconds, consider the test is correct // if the service doesn't answer after 10 tries. err = config.DialFromNode("udp", config.NodeIP, config.NodeUDPPort, 10, 10, sets.NewString()) </ins> if err != nil { framework.Failf("Failure validating that node port service STOPPED removed properly: %v", err) }

Discussion:
gce-master-scale-correctness Kubernetes e2e suite.[sig-network] Networking Granular Checks: Services should update nodePort: udp [Slow] ci-kubernetes-e2e-gce-scale-correctness.Overall kubetest.Test Kubernetes e2e suite.[sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Dynamic PV (filesystem volmode)] volumeMode should not mount / map unused volumes in a pod [LinuxOnly] Kubernetes e2e suite.[sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Generic Ephemeral-volume (default fs) (late-binding)] ephemeral should support two pods which have the same volume definition Kubernetes e2e suite.[sig-network] Services should be able to update service type to NodePort listening on same port number but different protocols 12/1/2021 17:36:39 ET No response No response /sig storage /sig network
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
/milestone v1.23 /priority important-soon
/assign aojea
/assign bowei
heh, what are the chances, two different test services took the same port The test was expecting to not receive any answer but the second service replies and makes the test fail link