jiebi/CodeConvo huggingface dataset:
Change:
// +optional VolumeMode *PersistentVolumeMode // This field can be used to specify either: <del> // * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot) </del> <ins> // * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot - Beta) </ins> // * An existing PVC (PersistentVolumeClaim) <del> // In order to use either of these DataSource types, the appropriate feature gate // must be enabled (VolumeSnapshotDataSource, VolumePVCDataSource) </del> <ins> // In order to use VolumeSnapshot object types, the appropriate feature gate // must be enabled (VolumeSnapshotDataSource) </ins> // 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

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:
}) }) <del> func getNextReadyConditionHeartbeatTime(clientSet clientset.Interface, nodeName string, prevHeartbeatTime metav1.Time) metav1.Time { var newHeartbeatTime metav1.Time Eventually(func() error { node, err := clientSet.CoreV1().Nodes().Get(nodeName, metav1.GetOptions{}) if err != nil { return err } _, readyCondition := testutils.GetNodeCondition(&node.Status, corev1.NodeReady) Expect(readyCondition.Status).To(Equal(corev1.ConditionTrue)) newHeartbeatTime = readyCondition.LastHeartbeatTime if prevHeartbeatTime.Before(&newHeartbeatTime) { return nil } return fmt.Errorf("heartbeat has not changed yet") }, 5*time.Minute, 5*time.Second).Should(BeNil()) return newHeartbeatTime </del> <ins> func getReadyConditionHeartbeatTime(clientSet clientset.Interface, nodeName string) time.Time { node, err := clientSet.CoreV1().Nodes().Get(nodeName, metav1.GetOptions{}) Expect(err).To(BeNil()) _, readyCondition := testutils.GetNodeCondition(&node.Status, corev1.NodeReady) Expect(readyCondition.Status).To(Equal(corev1.ConditionTrue)) return readyCondition.LastHeartbeatTime.Time </ins> } func expectLease(lease *coordv1beta1.Lease, nodeName string) error {

Discussion:
/assign /milestone v1.14
(Edit: Removed comment to ask for help, noticed open PR later... For context/help to measure change post merge: This is currently failing about 8% of the time in )
<img width="1095" alt="Screen Shot 2019-03-16 at 11 47 05 AM" src="https://user-"Think this is done
Change:
package autoscaling import ( <del> "time" </del> "k8s.io/pod-security-admission/api" <ins> "time" </ins> "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
gce-cos-autoscaling-hpa-cpu Kubernetes e2e suite.[sig-autoscaling] [Feature:HPA] [Serial] [Slow] Horizontal pod autoscaling (non-default behavior) with long upscale stabilization window should scale up only after the stabilization period Since it was in (first run at 2022-06-14 13:13 CEST failed, all subsequent runs failed too). https://k8s- Times out when waiting for scale down (), logs from (): I'm not sure why exactly, I have 2 ideas: It looks like the consumer briefly consumes 440 mCPU, which could result in a higher recommendation being generated HPA stabilises initial size of the consumer Increasing timeout should fix the issue No response_ /sig autoscaling
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
FYI
This was already reverted (and later the test got fixed and merged). /close
Closing this issue. <detailsIn response to : This was already reverted (and later the test got fixed and merged). 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:
hostAlreadyPresent[host] = struct{}{} continue } <del> if host != "_" { </del> <ins> if host != "" { </ins> ingressTLS.Hosts = append(ingressTLS.Hosts, host) } if secret != "" {

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: kubectl create ingress panics because there is no cmdutil.AddDryRunFlag What you expected to happen: Command to work How to reproduce it (as minimally and precisely as possible): Compile the upstream, run ` Anything else we need to know?: Environment: Kubernetes version (use ): upstream/dev /sig cli /kind bug /priority critical-urgent
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
Change:
"//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/intstr:go_default_library", "//staging/src/k8s.io/client-go/kubernetes:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/fake:go_default_library",

Discussion:
Create a deployment as described in section, and run 'kubectl describe deploy/testWhat happened: shows , while shows the current replicaset infomation What you expected to happen: shows the current replicaset infomation, while shows How to reproduce it (as minimally and precisely as possible): Create a deployment as follows, and wait its pod started. Then, run 'kubectl describe deploy/test Anything else we need to know?: Environment: Kubernetes version (use ): kubectl of 1.14+(I did not try older versions) 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 cli
/assign
Ok, can confirm here. With the old code, during a rollout the data is shown at OldReplicaSets (both the old and new RS) while with the patch during the rollout the NewReplicaSet contains the net one and the Old the old one ( obvious here) while the old exists. I'll make some more tests here and check if is there anything else in your PR that needs better verification, otherwise wer can follow with it! Thank you!
/triage accepted
Change:
name:        "test pod count", metricsName: "kubelet_running_pods", wants: ` <del> # HELP kubelet_running_pods [ALPHA] Number of pods currently running </del> <ins> # HELP kubelet_running_pods [ALPHA] Number of pods that have a running pod sandbox </ins> # TYPE kubelet_running_pods gauge kubelet_running_pods 2 `,

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 --kubelet metric should only count pods in state. But it incorrectly reports the sum of pods in + state. Only pods in state should be counted. Create a pod with sample yaml to create a pod that stays in state. Verify that pod we created is in state, Now let's count the total number of pods using Out of 15, 1 is in and rest are in state. But the corresponding metric from Prometheus dashboard returns 15. 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 node
Does it mean that pod after initial will be take into account for running pod metrics ? According the code, it counts sandboxes. Once Pod pause container is started, and it will be counted.
/triage accepted
As some comments in , the have a different meanings between and .
Yeah. But then that means metric ends up misleading the user. Would it be possible to use API Pod instead of runtime pod?
I may follow the rules in to make it consistent with
Please feel free to tag me for review once you submit the PR.
I am wondering if we should just update the documentation for stating explicitly that the results may not always match with the due to differences between them in what they consider as a pod. What do you think?
Agree. Generally, metrics should be simple to calculate. The current logic makes sense from the runtime side. Proposal 1: update the doc for . Proposal 2: rename it to something like or an accuracy name. Proposal 3: make it the same meaning as (which need some further calculation)
I think I will go with Proposal 1. The ideal thing would be Proposal 3, but I am afraid we might be underestimating the effort required. What do you think?
IIRC, is not intended to reflect the pod phase in the API server. It is used to expose the kubelet internal state: how many pods have running containers in the container runtime, and mainly for debugging purpose.

To make it more clear: to A pod is in phase when kubelet tries to create init container after pause container started.
Thanks Closing this because we have more clarity on what that metric is supposed to mean.
/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
Sorry closed it before noticing Reopened this bug.
Change:
all-push: all-container-registry push-manifest push-manifest: <del> docker manifest create --amend $(IMAGE):$(TAG) $(shell echo $(ALL_OS_ARCH) | sed -e "s~[^ ]*~$(IMAGE)-&:$(TAG)~g") set -x; for arch in $(ALL_ARCH.linux); do docker manifest annotate --os linux --arch $${arch} ${IMAGE}:${TAG} ${IMAGE}-linux-$${arch}:${TAG}; done </del> <ins> docker manifest create --amend $(IMAGE):$(TAG) $(shell echo $(ALL_OS_ARCH) | sed -e "s~[^ ]*~$(IMAGE):$(TAG)-&~g") set -x; for arch in $(ALL_ARCH.linux); do docker manifest annotate --os linux --arch $${arch} ${IMAGE}:${TAG} ${IMAGE}:${TAG}-linux-$${arch}; done </ins> # For Windows images, we also need to include the "os.version" in the manifest list, so the Windows node can pull the proper image it needs. # At the moment, docker manifest annotate doesn't allow us to set the os.version, so we'll have to it ourselves. The manifest list can be found locally as JSONs. # See: https://github.com/moby/moby/issues/41417

Discussion:
We could either: where appropriate - least amount of code change but cumbersome OS version in the tag instead of the repository /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
/sig windows
/kind bug
Change:
runningPodData = t.RunningPodCheck(pod) } <del> StopPod(client, pod) </del> <ins> StopPodAndDependents(client, pod) </ins> pod = nil // Don't stop twice. // There should be no dangling PVCs in the namespace now. There might be for

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: I0722 06:26:18.056] I0722 06:26:18.057] [Driver: csi-hostpath] I0722 06:26:18.057] I0722 06:26:18.057] [Testpattern: Generic Ephemeral-volume (default fs) [Feature:GenericEphemeralVolume] (late-binding)] ephemeral skipped 448 lines unfoldmore I0722 06:30:33.845] Jul 22 06:30:33.845: INFO: Wait up to 5m0s for pod "inline-volume-tester2-hhcbd" to be fully deleted I0722 06:31:06.117] Jul 22 06:31:06.117: INFO: Pod inline-volume-tester-74jqh has the following logs: /dev/sda1 on /mnt/test-0 type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30) I0722 06:31:06.117] I0722 06:31:06.117] Jul 22 06:31:06.117: INFO: Deleting pod "inline-volume-tester-74jqh" in namespace "ephemeral-9141" I0722 06:31:06.155] Jul 22 06:31:06.155: INFO: Wait up to 5m0s for pod "inline-volume-tester-74jqh" to be fully deleted I0722 06:31:38.264] Jul 22 06:31:38.264: FAIL: no dangling PVCs I0722 06:31:38.264] Expected I0722 06:31:38.265] <[]v1.PersistentVolumeClaim | len:1, cap:1: [ I0722 06:31:38.265] { I0722 06:31:38.265] TypeMeta: {Kind: "", APIVersion: ""}, I0722 06:31:38.

265] ObjectMeta: { skipped 315 lines unfold_more I0722 06:32:16.896] STEP: Destroying namespace "ephemeral-9141" for this suite. I0722 06:32:16.931] Jul 22 06:32:16.931: INFO: Namespace ephemeral-9141 was already deleted I0722 06:32:16.932] STEP: Destroying namespace "ephemeral-522" for this suite. I0722 06:32:16.966] Jul 22 06:32:16.966: INFO: Namespace ephemeral-522 was already del Anything else we need to know: /cc /sig storage /priority critical-urgent /milestone v1.19
I have tracked this down and it looks like that changes were made in that affected how Pods were being deleted in the e2e framework (specifically commit ). This caused failures in other tests, so the commit was reverted in I will have a fix open shortly that uses foreground deletion only for these storage tests. /assign /cc Side note: I see already saw this
Change:
"apply_crd_test.go", "apply_test.go", "main_test.go", <ins> "status_test.go", </ins> ], tags = [ "etcd",

Discussion:
What happened: I've performed server-side apply on the subresource. e.g. The request body is the following for example: The CRD itself has status commonly defined as: in the resulting openAPIv3 validation the correct object annotations are set for listType & listMapKey (thanks to controler-gen v0.2.5) What you expected to happen: The patch is applied to the status subresource, and the is properly set. However, one of two things happens: if the status subfield conditions don't exist the request passes through and properly sets the field. But the isn't set if the specific status condition type exits the request fails with 409 Conflict. It conflicts with other managers, e.g. since the is empty. if the exist beforehand for the status subresource, they are cleared after server-side apply on the subresource and become empty. Anything else we need to know?: This is similar to Also somewhat related to Environment: Kubernetes version (use ):
/wg apply
/sig api-machinery
thanks for the detailed post, you're absolutely right that this is related to the two issues that you mentioned. I don't see how we would be able to fix this in 1.18 or any version before that, we're planning on fixing it in 1.19. We should probably update the documentation to mention that this doesn't work for sub-resources, and maybe even disable it altogether for sub-resources.
I'd rather have it working...buggily(that is via ) than having it disabled altogether.
We trying to find out what this doesn’t work and see if we can back port the fix. We’ll keep you posted, thanks!
I can't reproduce this bug right now, would you mind sharing the CRD and exact reproduction steps?
Sure. The server-side application I've investigated in This is the CRD definition: my experimentations are in on line I've changed whether I've used force or not. The raw HTTP req/resp should be written to the output due to
Let me know if there's anything more I can do to help.
The strategy overriding the metadata in status updates of CRD and CR objects seems like it would definitely cause this. were you able to follow the steps at
Change:
"errors" "fmt" "path" <ins> "path/filepath" </ins> "strings" "time"

Discussion:
I am trying to create a configmap from a file using the "kubectl create configmap myconfigmap --from-file=game.properties" The game.properties consists of the following key value pairs The command is failing with the error "game.properties" is not a valid key name for a ConfigMap: a valid config key must consist of alphanumeric characters, '-', '' or '.' (e.g. '', or 'KEYNAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+') Also, with the same file (game.properties), i tried creating the configmap using "kubectl create configmap myconfigmap --from-file=game-properties-key=game.properties" and the configMap is getting created successfully. I tried creating a secret using the example given in kubernetes documentation ie kubectl create secret generic db-user-pass --from- --from- I am getting the same error for secrets as well This command was working a few weeks ago. I haven't changed my kubectl version since then. Kubectl version: 1.9.0 I also tried the same command with 1.7, 1.6 and 1.4 version and am getting the same error. /sig cli /kind bug
what server version do you have (output of )? dots are allowed in 1.4.x+ ( in )
Kubectl version: Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-11T23:27:35Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"windows/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-28T23:56:03Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
I'm having the same issue trying to add yaml files. I've tried several files and get the same error on all of them? I'm on a mac and just did a new install of kubctl with homebrew, which was v1.8.0.
Is there any update on this?

The same file is not working with a 1.4.6 version as well. Is there some specific way in which we need to specify the key value pairs in a config map using the file method?
not really, the described scenario works as expected for me:
I finally got what is wrong. When i specify the file path, i get the error specified. If the file is in the same location from where i am running the command the command executes successfully. eg: kubectl create configmap myconfigmap1 --from-file="C:UsersanshenoDesktop" gives me the error error: "C:UsersanshenoDesktop" is not a valid key name for a ConfigMap: a valid config key must consist of alphanumeric characters, '-', '' or '.' (e.g. '', or 'KEYNAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')
ah, great. will fix that. in the meantime, you can do
Thanks a lot!. One more observation was that the command works if you specify the path to the directory which contains the file instead of the path to the file itself.
Hi, what would be eta of this fix? Also, will it be available in all the versions of kubectl?
it will be in 1.11, targeted for end of june ()
Change:
service           v1.Service isInternalSvc     bool expectCreateError bool <ins> wrongRGAtDelete   bool </ins> }{ { desc:    "external service should be created and deleted successfully",

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: controller-manager is stuck in deleting an incorrectly configured LB type service. it cannot be recovered until restarted. What you expected to happen: controller-manager should recover. At least it should allow us to create the service without restarting it. How to reproduce it (as minimally and precisely as possible): put a random IP in above yaml and make sure the resource group doen't exist. Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig azure
I also want to add that the above repro is stuck in 403. It's possible for it to be stuck in 404 as well when the SP has the right permission.
Can you share the log for 404?
Thanks for reporting the issue. /assign Do you mean other services couldn't be configured when this happens?
correct.
FYI, we had the same issue when the Idle Timeout annotation was set to "3" which isn't a supported case. Will this PR also cover this edge case ?
Unfortunately , this is still not fixed. The idle timeout is not 403 or 404. We need another fix for this (and possibly more for other annotations)
Change:
} func sleepUpTo(d time.Duration) { <del> time.Sleep(time.Duration(rand.Int63n(d.Nanoseconds()))) </del> <ins> if d.Nanoseconds() > 0 { time.Sleep(time.Duration(rand.Int63n(d.Nanoseconds()))) } </ins> } func createAllResources(configs []testutils.RunObjectConfig, creatingTime time.Duration) {

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: e2e test panic in test What you expected to happen: no panic How to reproduce it (as minimally and precisely as possible): start " [Feature:ManualPerformance] should be able to handle 3 pods per node" e2e test on a 3-node cluster Anything else we need to know?: panic info : ! After some digging find why. Because the cluster size is 3 that d is 0 in sleepUpTo func which causes rand.Int63n panic happy to fix this. Environment: Kubernetes version (use ):1.7.3 Cloud provider or hardware configuration*: bare-metal OS (e.g. from /etc/os-release): ubuntu Kernel (e.g. ): 16.04 Install tools: kubeadm Others:
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig Testing
just add a sanity check is fine I think
It seems that the count of pods is 0.
pod count is not 0, is 9(33)
If totalPods less than throughput, in our case, totalPods is 9, throughput is 10, the creatingTime will be 0, which makes rand.Int63n panic
or throughput is getting from env LOADTESTTHROUGHPUT, safe to add a sanity check
If totalPods less than throughput, in our case, totalPods is 9, throughput is 10, the creatingTime will be 0, which makes rand.Int63n panic agree.