jiebi/CodeConvo huggingface dataset:
Code change:
} // CASE B: <ins> // if headless service then we bail out early (no clusterIPs management needed) if len(oldService.Spec.ClusterIPs) > 0 && oldService.Spec.ClusterIPs[0] == api.ClusterIPNone { return nil, nil, nil } </ins> // Update service from non-ExternalName to ExternalName, should release ClusterIP if exists. if oldService.Spec.Type != api.ServiceTypeExternalName && service.Spec.Type == api.ServiceTypeExternalName { toRelease = make(map[api.IPFamily]string)

Related discussion:
text: <!-- 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 --Patching a Kubernetes service failed with I the following yaml documents Create an external name service Change to to an ClusterIP Service Try to change it back to an external name service Kubernetes version (use ):Cloud provider or hardware configuration:
/sig node /sig api-machinery
Unsure if Service is part of networking /sig networking
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Unsure if Service is part of networking 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
/sig network
/remove-sig node
/cc /triage accepted
It is part of networking :), actually this part of Services is being revisited these days /assign
ack.
/sig network
Please don't triage/accept issues unless you're SURE they are your sig's. This fell through cracks.
/assign
this does not repo on: Here is what i did: service (the same one above) the service and change to =OK the service and change to =OK I have also performed step 3 using and the result is also OK /triage needs-information
I was using client v1.21.0 - is it resolved in newer kubectl 1.21.x patches?
please do. And also please share the exact steps you used were you using kubectl edit? or replace? or patch?
It's in the description - kubectl apply
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accepted - working on a fix. 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 working on a fix
to confirm does the merged PR allow you to now change the type from to ? Or does it still produce an error with the difference it is reported properly vs. INTERNAL_ERROR? If it's the former can we cherry pick this PR back to supported K8s versions?
Code change:
} // CASE B: <ins> // if headless service then we bail out early (no clusterIPs management needed) if len(oldService.Spec.ClusterIPs) > 0 && oldService.Spec.ClusterIPs[0] == api.ClusterIPNone { return nil, nil, nil } </ins> // Update service from non-ExternalName to ExternalName, should release ClusterIP if exists. if oldService.Spec.Type != api.ServiceTypeExternalName && service.Spec.Type == api.ServiceTypeExternalName { toRelease = make(map[api.IPFamily]string)

Related discussion:
text: the former and we should be able to cherry pick it.
for another look.
Cherry picks made: 22 21 20
Code change:
package proxy import ( <ins> "bytes" </ins> "fmt" "runtime"

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: MarshalToYamlForCodecs adds an indent to the yaml output. This code can be combined with PrintBytesWithLinePrefix 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:
/assign rpothier
/sig cluster-lifecycle
/priority important-soon
Code change:
ginkgo.It("should grab all metrics from a ControllerManager.", func() { ginkgo.By("Proxying to Pod through the API server") <del> // Check if master Node is registered nodes, err := c.CoreV1().Nodes().List(context.TODO(), metav1.ListOptions{}) framework.ExpectNoError(err) var masterRegistered = false for _, node := range nodes.Items { if strings.HasSuffix(node.Name, "master") { masterRegistered = true } } </del> if !masterRegistered { framework.Logf("Master is node api.Registry. Skipping testing ControllerManager metrics.") return

Related discussion:
text: MetricsGrabber tests failing when scheduler & controller-manager not visible. In managed offerings, like GKE, scheduler and controller-manager are not visible causing BeforeSuite of MetricsGrabber to fail. Test is failing then control plane pods can't be found (as on GKE): HasControlPlanePods was in /assign
/sig instrumentation
Just removing this check allows tests to run without problems (some skipped, one passing).
/triage accepted
Code change:
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="134.481,503.5 124.481,508.5 126.981,503.5 124.481,498.5 "/> </g> <g> <del> <rect style="fill: #ffffff" x="372.025" y="477.5" width="95.95" height="54"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="372.025" y="477.5" width="95.95" height="54"/> <text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="420" y="500.4"> <tspan x="420" y="500.4">kubelet</tspan> <tspan x="420" y="516.4">info service</tspan> </del> <ins> <rect style="fill: #ffffff" x="372.024" y="477.5" width="95.95" height="54"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="372.024" y="477.5" width="95.95" height="54"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="419.999" y="500.4"> <tspan x="419.999" y="500.4">kubelet</tspan> <tspan x="419.999" y="516.4">info service</tspan> </ins> </text> </g> <ins> <text font-size="12.8" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="221.612" y="111.49"> <tspan x="221.612" y="111.49"></tspan> </text> </ins> </svg>

Related discussion:
text: Architecture picture: says kubecfg is deprecated. The architecture picture should be updated to show kubectl instead of kubecfg.
ref /cc
Code change:
# move into staging and save the dependencies for everything in order mkdir -p "${TMP_GOPATH}/src/k8s.io" for repo in $(ls ${KUBE_ROOT}/staging/src/k8s.io); do <del> # we have to skip api because it does not depend on anything if [ "${repo}" == "api" ]; then continue fi </del> # we skip metrics because it's synced to the real repo manually if [ "${repo}" == "metrics" ]; then continue

Related discussion:
text: But it doesn't have the Godeps/ folder. add the Godeps/. Ideally, we should not let the IntOrString pull in so much dependency to
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Code change:
if volumeInDSW { // Some pod needs the volume, don't clean it up and hope that // reconcile() calls SetUp and reconstructs the volume in ASW. <del> klog.V(4).InfoS("Volume exists in desired state, skip cleaning up mounts", "pod", klog.KObj(reconstructedVolume.pod), "volumeSpecName", volume.volumeSpecName) </del> <ins> klog.V(4).InfoS("Volume exists in desired state, skip cleaning up mounts", "podName", volume.podName, "volumeSpecName", volume.volumeSpecName) </ins> continue } // No pod needs the volume. <del> klog.InfoS("Could not construct volume information, cleaning up mounts", "pod", klog.KObj(reconstructedVolume.pod), "volumeSpecName", volume.volumeSpecName, "error", err) </del> <ins> klog.InfoS("Could not construct volume information, cleaning up mounts", "podName", volume.podName, "volumeSpecName", volume.volumeSpecName, "error", err) </ins> rc.cleanupMounts(volume) continue }

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-gci-gce-serial [sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] In-tree Volumes [Driver: gluster] [Testpattern: Pre-provisioned PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: blockfs] [Testpattern: Pre-provisioned PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: dir-bindmounted] [Testpattern: Pre-provisioned PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: dir-link-bindmounted] [Testpattern: Pre-provisioned PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: dir-link] [Testpattern: Pre-provisioned PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: dir] [Testpattern: Pre-provisioned PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: gce-localssd-scsi-fs] [Serial] [Testpattern: Pre-provisioned PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] In-tree Volumes [Driver:
Code change:
if volumeInDSW { // Some pod needs the volume, don't clean it up and hope that // reconcile() calls SetUp and reconstructs the volume in ASW. <del> klog.V(4).InfoS("Volume exists in desired state, skip cleaning up mounts", "pod", klog.KObj(reconstructedVolume.pod), "volumeSpecName", volume.volumeSpecName) </del> <ins> klog.V(4).InfoS("Volume exists in desired state, skip cleaning up mounts", "podName", volume.podName, "volumeSpecName", volume.volumeSpecName) </ins> continue } // No pod needs the volume. <del> klog.InfoS("Could not construct volume information, cleaning up mounts", "pod", klog.KObj(reconstructedVolume.pod), "volumeSpecName", volume.volumeSpecName, "error", err) </del> <ins> klog.InfoS("Could not construct volume information, cleaning up mounts", "podName", volume.podName, "volumeSpecName", volume.volumeSpecName, "error", err) </ins> rc.cleanupMounts(volume) continue }

Related discussion:
text: local][LocalVolumeType: tmpfs] [Testpattern: Pre-provisioned PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] There are also variations of this test that are flaking (e.g. ) but not failing -- please consult TestGrid. TestGrid says sometime between these commits: First failing run at March 17 18:29 PDT Most of them have an error that looks like this: An example Spyglass link for more details: Triage shows a huge spike for these failures: /sig storage cloud-provider /area provider/gcp /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
/cc
/assign
/cc cc'ing as a followup from Slack
/assign to help investigate
these were the test-infra changes between the passing/failing
This is in for one of the failed tests: This nil pointer deference happens on line 411. Here are the surrounding lines: We're trying to use the on line 402, however in the case that , is .
Those labels are not set on the issue: <detailsIn response to : /remove-kind flake 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
/unassign
Code change:
Factor:   rbdImageWatcherFactor, Steps:    rbdImageWatcherSteps, } <ins> needValidUsed := true // If accessModes contain ReadOnlyMany, we don't need check rbd status of being used. if b.accessModes != nil { for _, v := range b.accessModes { if v != v1.ReadWriteOnce { needValidUsed = false break } } } </ins> err := wait.ExponentialBackoff(backoff, func() (bool, error) { used, rbdOutput, err := util.rbdStatus(&b) if err != nil { return false, fmt.Errorf("fail to check rbd image status with: (%v), rbd output: (%s)", err, rbdOutput) } <del> return !used, nil </del> <ins> return !needValidUsed || !used, nil </ins> }) // Return error if rbd image has not become available for the specified timeout. if err == wait.ErrWaitTimeout {

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When use ceph as storageclass, i set accessModes: ReadOnlyMany, and create pods using the claim, only one pod would be running and the others on different nodes would get stuck on ContainerCreating. But if the pods are all on same node, it works fine. What you expected to happen: Pods on different nodes can mount ceph rbd volume. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.2 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): 3.10.0-327.18.2.el7.x86_64 Kernel (e.g. ): CentOS Linux release 7.2.1511 (Core) Install tools: kubeadm Others:
/sig storage
/assign
, how would this work? For example, how do you put the initial contents of the RBD volume on it if it is in the ReadOnlyMany access mode? How would you use this feature? As a cheap way of sharing files across a Kubernetes cluster? I'm just interested. -ben england
Do we really want to support ? I have the same questions as mentioned above. If we set the PVC AccessMode to , then the field in will need to be set true ? If so, for the first time, in , we will mount the device without formatting, is that intended ? We need to format the device manually before we use it ? /cc FYI: also there is an issue related to this:
We have this same problem for GCE PD, which supports ReadOnlyMany. You need to mount the volume first as RWO, in order to format the filesystem and populate it with data (mounting a read only volume with no data on it seems pointless). Then you have to fully unmount/detach it, and then you can deploy pods using it as ROX. Basically, you can dynamically provision it in RWO to format + populate data. But afterwards, you need to manually create a different PV/PVC for ROX
continuation
Code change:
import ( "context" "fmt" <ins> "sync" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" clientset "k8s.io/client-go/kubernetes" api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/master/ports" <ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" </ins> "k8s.io/kubernetes/test/e2e/system" "k8s.io/klog"

Related discussion:
text: <!-- 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-gce ci-kubernetes-e2e-gci-gce Which test(s) are flaking: [sig-storage] In-tree Volumes [Driver: hostPath] [Testpattern: Inline-volume (default fs)] subPath should support readOnly file specified in the volumeMount [LinuxOnly] [sig-storage] In-tree Volumes [Driver: emptydir] [Testpattern: Inline-volume (default fs)] subPath should support file as subpath [LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: dir-link] [Testpattern: Pre-provisioned PV (default fs)] volumes should allow exec of files on the volume [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: blockfs] [Testpattern: Pre-provisioned PV (default fs)] subPath should support existing single file [LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: dir-bindmounted] [Testpattern: Pre-provisioned PV (default fs)] volumes should store data [sig-storage] In-tree Volumes [Driver: gcepd] [Testpattern: Inline-volume (default fs)] volumes should store data [sig-storage] In-tree Volumes [Driver: gluster] [Testpattern: Inline-volume (default fs)] subPath should be able to unmount after the subpath directory is deleted [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: tmpfs] [Testpattern: Pre-provisioned PV (default fs)] subPath should be able to unmount after the subpath directory is deleted [sig-storage] In-tree Volumes [Driver: gcepd] [Testpattern: Dynamic PV (default fs)] subPath should support existing directory [sig-storage] In-tree Volumes [Driver: gluster] [Testpattern: Inline-volume (default fs)] subPath should support non-existent path [sig-storage] In-tree Volumes [Driver: hostPathSymlink] [Testpattern: Inline-volume (default fs)] subPath should support existing directories when readOnly specified in the volumeSource [sig-storage] In-tree Volumes [Driver: hostPath] [Testpattern: Inline-volume (default fs)]
Code change:
import ( "context" "fmt" <ins> "sync" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" clientset "k8s.io/client-go/kubernetes" api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/master/ports" <ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" </ins> "k8s.io/kubernetes/test/e2e/system" "k8s.io/klog"

Related discussion:
text: subPath should be able to unmount after the subpath directory is deleted [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: tmpfs] [Testpattern: Pre-provisioned PV (default fs)] subPath should support existing directories when readOnly specified in the volumeSource [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: dir-link-bindmounted] [Testpattern: Pre-provisioned PV (default fs)] subPath should support existing single file [LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (ext3)] volumes should allow exec of files on the volume [sig-storage] In-tree Volumes [Driver: gcepd] [Testpattern: Dynamic PV (default fs)(allowExpansion)] volume-expand Verify if offline PVC expansion works [sig-storage] In-tree Volumes [Driver: gcepd] [Testpattern: Dynamic PV (ext3)] volumes should store data Testgrid link: Reason for failure: Failure fetching metrics: Anything else we need to know: This appears to have restarted abruptly around 2/11-2/12 /sig storage /priority important-soon
xref I think we have a general failure to start containers reliably. Almost every instance of these test failures contained the pod status error of "OCI runtime start failed: container process is already dead: unknown"
after sweeping a bunch of the in-tree test failures, almost all seemed to have as a root cause, triggered by very short-lived containers used to check file content or permissions. The only test I saw failing that didn't seem to fit that was: [sig-storage] In-tree Volumes [Driver: nfs] [Testpattern: Dynamic PV (default fs)] subPath should support non-existent path [sig-storage] In-tree Volumes [Driver: nfs] [Testpattern: Dynamic PV (default fs)] subPath should support existing directory examples: I'd recommend repurposing this issue to address that specifically and leave the OCI issue for the short-lived container issue
Here's a PR for context: So, I think this PR is another example of flakes. Here are some links to previous runs: and same message: This prow: has the above message and a few more, all A lot of in-tree volume issues, but there were some persistent volume ones too.
Code change:
import ( "context" "fmt" <ins> "sync" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" clientset "k8s.io/client-go/kubernetes" api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/master/ports" <ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" </ins> "k8s.io/kubernetes/test/e2e/system" "k8s.io/klog"

Related discussion:
text: But, that showed up once so far from what I've seen.
The "error getting c-m metrics" failures appear to have just restarted:
/priority critical-urgent bumping priority since we're seeing significant numbers of failures that just started in the last two days
this is failing many test runs per day, do you have updated status on this?
I haven't had chance to fully debug this yet. looked into this little bit and he suspected that these tests started to flake same time around was merged. I should be able to take a closer look tomorrow.
This occurrence fails because it's trying to get the metrics from the kube-controller-manager pod but it is not ready until one minute later if we grep in the kube-apiserver for the controller pod name we can observe that after the pod is up it starts to get 200 instead of 404
keeping open until shows this is resolved
seen again in
this time the container is running but still it can't find it
the errors comes from the request to the apiserver on How can we check that the pod is found and that the apiserver found it?
the first successful get of /metrics logged by the controller manager in that run is at: We're also not checking the error in the once.Do to make sure the pod was running, and once running, we should probably then also check the metrics path on the pod. Maybe something like this:
still happening: message logging missed using the correct errors, so the messages aren't helpful:
what's this stack trace in the apiserver? is this related? a 503 shouldn't cause that, right?
again it seems is not really waiting because it fails just 200 ms after the INFO msg, I think is because it checks if the pod is running, but the message is that the pod doesn't really exist. The fact that there are 9 tests failing with the same error and we are using has to be related to the way Ginkgo use parallel.
It turns out that the method used to wait for the controller manager pod fails if the pod doesn't exist
Ah, so first we should wait for the pod to exist, then be ready, then return metrics
This start to look promising
yes, looks good. thanks for all the work /close
Closing this issue. <detailsIn response to : yes, looks good.
Code change:
import ( "context" "fmt" <ins> "sync" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" clientset "k8s.io/client-go/kubernetes" api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/master/ports" <ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" </ins> "k8s.io/kubernetes/test/e2e/system" "k8s.io/klog"

Related discussion:
text: thanks for all the work 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
Fixed by
Code change:
- --api-override={{ prometheus_to_sd_endpoint }} - --pod-id=$(POD_NAME) - --namespace-id=$(POD_NAMESPACE) <del> volumeMounts: - name: ssl-certs mountPath: /etc/ssl/certs </del> env: - name: POD_NAME valueFrom:

Related discussion:
text: Currently there are several, and some of them have problems with excessive logging could you please do this?
Any estimate on this fix? Asking because I'm seeing the issue referenced in
It was already fixed in head and in 1.8 long time ago. Fix was merged to 1.7 recently, so we are just waiting for new patch release.