jiebi/CodeConvo huggingface dataset:
Change:
echo "${color_red}Could not find subnetwork with region ${REGION}, network ${NETWORK}, and project ${NETWORK_PROJECT}" } <ins> # Sets up Cloud NAT for the network. # Assumed vars: #   NETWORK_PROJECT #   REGION #   NETWORK function create-cloud-nat-router() { if [[ ${GCE_PRIVATE_CLUSTER:-} == "true" ]]; then gcloud compute routers create "$NETWORK-nat-router"  --project $NETWORK_PROJECT  --region $REGION  --network $NETWORK gcloud compute routers nats create "$NETWORK-nat-config"  --project $NETWORK_PROJECT  --router-region $REGION  --router "$NETWORK-nat-router"  --nat-all-subnet-ip-ranges  --auto-allocate-nat-external-ips fi } </ins> function delete-all-firewall-rules() { if fws=$(gcloud compute firewall-rules list --project "${NETWORK_PROJECT}" --filter="network=${NETWORK}" --format="value(name)"); then echo "Deleting firewall rules remaining in network ${NETWORK}: ${fws}"

Discussion:
Public IPs are expensive resources. Given that we're running scalability tests on 5k-node clusters, we are unnecessarily consuming 5k IPs which is a lot. We should switch our tests so that nodes have only private IP addresses. We are going to do that by configuring NAT so that nodes can talk to outside world (e.g. to download image from dockerhub). But that also requires changing some correctness tests which assume public IPs.
To summarize recent work: setting up private gce clusters with nat, feature is gated via the env test and dashboard with correctness tests on gce private cluster - https://k8s- 27 tests fail on fixing the tests - should fix majority of them
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 /lifecycle frozen
- is there anything missing to be done here?
No, we can close this one. It was done long time ago. Thanks for catching /close
Closing this issue. <detailsIn response to : No, we can close this one. It was done long time ago. Thanks for catching 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:
// Attaches the disk to the kubelet's host machine. AttachDisk(b fcDiskMounter) (string, error) // Detaches the disk from the kubelet's host machine. <del> DetachDisk(disk fcDiskUnmounter, mntPath string) error </del> <ins> DetachDisk(disk fcDiskUnmounter, devName string) error </ins> } // utility to mount a disk based filesystem

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?: /kind bug What happened: When user uses fc volume plugin, device file on operating system such as /dev/sdX remains after deleting a Pod. After deleting the Pod, PVC and PV, cluster admin or external-provisioner might delete the disk from the storage, therefore the block device on the worker node should be cleaned up. The photon volume plugin already has this functionality in the removeFromScsiSubsystem(). Also the gce volume plugin has similar functionality in the udevadmChangeToDrive() too. photon: echo 1 /sys/block/<dev name/device/delete gce: udevadm trigger --action=change --property-match=DEVNAME=%s Also os-brick library in the OpenStack Cinder component uses same way with photon driver. What you expected to happen: The device file on operating system such as /dev/sdX will be cleaned up after deleting PVs. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: KVM OS (e.g. from /etc/os-release): Fedora 25 Kernel (e.g. ):Install tools: local-up- 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 storage
I'll work on this.
Reiterating the mentions to trigger a notification: <detailsIn response to : I'll work on this. 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:
} // Skip non-memory backed volumes belonging to terminated pods volume := volumeToMount.VolumeSpec.Volume <ins> if volume == nil { continue } </ins> if (volume.EmptyDir == nil || volume.EmptyDir.Medium != v1.StorageMediumMemory) && volume.ConfigMap == nil && volume.Secret == nil { continue

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? No What keywords did you search in Kubernetes issues before filing this one? panic, findAndRemoveDeletedPods Is this a BUG REPORT or FEATURE REQUEST? BUG REPORT Kubernetes version (use ): 1.5.1 Environment: Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): gci 56 (8938.0.0) Kernel (e.g. ): Install tools: Others: What happened: I created a pod and it went into the failed state. I couldn't find any info about the failure, so I logged into the GKE node and ran "journalctl -u kubelet" and saw: When I tail the log, the error messages continue indefinitely with multiple messages printed every second. Digging into I see: So I'm wondering if perhaps there is a bug where is in some cases. What you expected to happen: I did not expect to see the kublet log full of "invalid memory address or nil pointer dereference" errors. How to reproduce it (as minimally and precisely as possible): Sorry, I don't have a good way to reproduce this error. Anything else do we need to know: I'm running several pods, each with a GCE persistent disk mounted. When the pods finish, I run a different set of pods that mount the same persistent disks. I've seen various issues in past K8S versions where persistent disks don't get detached and reattached properly across K8S nodes, but so far with 1.5.1 it seems to have been working well up until now.
CC
guess it doesn't matter how it happens; it does. creating a fix.
If the pod is still around(even if failed state), can you paste output of . Just wondering how did the pod get in that state.
More information about the failed pod ():
looking at seems that there is a field for temporal volumes (configmaps, secrets, etc) and a field for persistent volumes and only one is set at a time.
Thanks for the quick PR!
Change:
for _, minion := range list.Items { status, err := health.DoHTTPCheck(r.makeMinionURL(minion.ID), r.client) if err != nil { <del> glog.Errorf("%s failed health check with error: %s", minion, err) </del> <ins> glog.Errorf("%#v failed health check with error: %s", minion, err) </ins> continue } if status == health.Healthy {

Discussion:
For example: struct field tag not compatible with reflect.StructTag.Get missing argument for Errorf("%v"): format reads arg 2, have only 1 args range variable pod enclosed by function struct field tag not compatible with reflect.StructTag.Get arg minion for printf verb %s of wrong type: unreachable code unreachable code
Those all look really important
I'm going to fix this unless I hear that someone else is working on this in the next couple minutes.
Change:
# Find all of the built client binaries local platform platforms platforms=($(cd "${LOCAL_OUTPUT_BINPATH}" ; echo */*)) <del> for platform in "${platforms[@]}" ; do </del> <ins> for platform in "${platforms[@]}"; do </ins> local platform_tag=${platform///-} # Replace a "/" for a "-" <del> kube::log::status "Building tarball: client $platform_tag" </del> <ins> kube::log::status "Starting tarball: client $platform_tag" </ins> <del> local release_stage="${RELEASE_STAGE}/client/${platform_tag}/kubernetes" rm -rf "${release_stage}" mkdir -p "${release_stage}/client/bin" </del> <ins> ( local release_stage="${RELEASE_STAGE}/client/${platform_tag}/kubernetes" rm -rf "${release_stage}" mkdir -p "${release_stage}/client/bin" </ins> <del> local client_bins=("${KUBE_CLIENT_BINARIES[@]}") if [[ "${platform%/*}" == "windows" ]]; then client_bins=("${KUBE_CLIENT_BINARIES_WIN[@]}") fi </del> <ins> local client_bins=("${KUBE_CLIENT_BINARIES[@]}") if [[ "${platform%/*}" == "windows" ]]; then client_bins=("${KUBE_CLIENT_BINARIES_WIN[@]}") fi </ins> <del> # This fancy expression will expand to prepend a path # (${LOCAL_OUTPUT_BINPATH}/${platform}/) to every item in the # KUBE_CLIENT_BINARIES array. cp "${client_bins[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/client/bin/" </del> <ins> # This fancy expression will expand to prepend a path # (${LOCAL_OUTPUT_BINPATH}/${platform}/) to every item in the # KUBE_CLIENT_BINARIES array. cp "${client_bins[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/client/bin/" </ins> <del> kube::release::clean_cruft </del> <ins> kube::release::clean_cruft </ins> <del> local package_name="${RELEASE_DIR}/kubernetes-client-${platform_tag}.tar.gz" kube::release::create_tarball "${package_name}" "${release_stage}/.." </del> <ins> local package_name="${RELEASE_DIR}/kubernetes-client-${platform_tag}.tar.gz" kube::release::create_tarball "${package_name}" "${release_stage}/.." ) & </ins> done <ins> kube::log::status "Waiting on tarballs" wait || { kube::log::error "client tarball creation failed"; exit 1; } </ins> } # Package up all of the server binaries

Discussion:
Filing for This code is wrong The local needs to be on a separate line from the command execution, and we need to be resilient to not existing on OS X, like:
For once I was actually watching the output of a build and noticed that I was seeing an error about md5sum not being found. I'm building on a mac using boot2docker. The short_hash function () works fine on my mac as md5 does exist.
Actually, I'm just going to fix this as a follow-on to .
Thank you!
Change:
// However, we need to tweak it e.g. to differentiate GET from LIST. verb := canonicalVerb(strings.ToUpper(req.Method), scope) if requestInfo.IsResourceRequest { <del> MonitorRequest(req, verb, requestInfo.APIGroup, requestInfo.APIVersion, requestInfo.Resource, requestInfo.Subresource, scope, component, contentType, code, responseSizeInBytes, elapsed) </del> <ins> requestTerminationsTotal.WithLabelValues(cleanVerb(verb, req), requestInfo.APIGroup, requestInfo.APIVersion, requestInfo.Resource, requestInfo.Subresource, scope, component, codeToString(code)).Inc() </ins> } else { <del> MonitorRequest(req, verb, "", "", "", requestInfo.Path, scope, component, contentType, code, responseSizeInBytes, elapsed) </del> <ins> requestTerminationsTotal.WithLabelValues(cleanVerb(verb, req), "", "", "", requestInfo.Path, scope, component, codeToString(code)).Inc() </ins> } }

Discussion:
What happened: When the kube-apiserver timeouts on a request, we end up doubling the counts measured in : apiserverrequestcounts apiserverrequesttotal apiserverrequestlatencies apiserverrequestlatenciessummary apiserverrequestdurationseconds apiserverresponsesizes What you expected to happen: We only count our requests a single time in our metrics. How to reproduce it (as minimally and precisely as possible): Add a 60 second sleep in the func . You may want to filter by resource (like pods or something) and verb for testing (otherwise this will be quite annoying). Manually hit that endpoint and look at the metric output. /assign
/sig api-machinery instrumentation /cc
Thanks for filing. Can we, while fixing this, add a metric counting timed-out requests? You can't tell from the latency distribution, even if we made the buckets more useful.
Yeah, that's the current plan. I've relayed the idea to offline and he has concurred.
Change:
Type  string } <ins> var ( autoSubnetIPRange = &net.IPNet{ IP:   net.ParseIP("10.128.0.0"), Mask: net.CIDRMask(9, 32), } ) </ins> var providerIdRE = regexp.MustCompile(`^` + ProviderName + `://([^/]+)/([^/]+)/([^/]+)$`) func getProjectAndZone() (string, string, error) {

Discussion:
/kind bug What happened: Continuation of . The fix to that bug only takes the first subnetwork in the correct region. However, if the user manual subnets in the region that the cluster exists, it's possible the cloudprovider could choose the wrong subnet. What you expected to happen: If no subnet is specified for a non-legacy network, always take the subnet which was automatically created. /assign /sig network /area platform/gce
Change:
// ListKubeContainers lists running k8s CRI pods func (runtime *CRIRuntime) ListKubeContainers() ([]string, error) { <del> out, err := runtime.crictl("pods", "-q").CombinedOutput() </del> <ins> // Disable debug mode regardless how the crictl is configured so that the debug info won't be // iterpreted to the Pod ID. args := []string{"-D=false", "pods", "-q"} out, err := runtime.crictl(args...).CombinedOutput() </ins> if err != nil { return nil, errors.Wrapf(err, "output: %s, error", string(out)) }

Discussion:
prints out some warning messsage: And the pod on that node is not removed eventually. all the pods could be removed at last. Have a crictl installed on the node with the config like this, And then run below command, No response <details</details<details</details<details</details<details</details<details</details<details</details
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 cluster-lifecycle /assign
The root cause is that when the debug mode is configured, will print out some debug message, e.g. DEBU[0000] get runtime connection DEBU[0000] ListPodSandboxRequest: &ListPodSandboxRequest{Filter:&PodSandboxFilter{Id:,State:nil,LabelSelector:map[string]string{},},} DEBU[0000] ListPodSandboxResponse: While our code interpret everything here as a Pod ID and try to rm them.
We cannot stop other to enable the debug mode for but we should ignore those debug message in our code.
Change:
"fmt" v1 "k8s.io/api/core/v1" <del> schedulingv1 "k8s.io/api/scheduling/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" </del> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" kubeapi "k8s.io/kubernetes/pkg/apis/core"

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
const ( containerPollTime = 1 * time.Second <ins> lostPodPollTime   = 1 * time.Minute </ins> podRelistPeriod   = 5 * time.Minute )

Discussion:
In , there is a local constant named containerPollTime that is put to two very different uses --- waiting for a pod to come up, and recovering from pods getting "lost". The former needs to be very responsive, but the latter does not (but is still costly when the number of pods grows). The value is currently set to one second, and that makes both things happen frequently. It would be better if there were two different constants, so the monitoring for lost pods can be less frequent.
Change:
return nil } return &priorityMetadata{ <del> podSelector:             getSelector(pod, pmf.serviceLister, pmf.controllerLister, pmf.replicaSetLister, pmf.statefulSetLister), podFirstServiceSelector: getFirstServiceSelector(pod, pmf.serviceLister), podTopologySpreadMap:    tpSpreadMap, </del> <ins> podSelector:          getSelector(pod, pmf.serviceLister, pmf.controllerLister, pmf.replicaSetLister, pmf.statefulSetLister), podTopologySpreadMap: tpSpreadMap, </ins> } } <del> // getFirstServiceSelector returns one selector of services the given pod. func getFirstServiceSelector(pod *v1.Pod, sl corelisters.ServiceLister) (firstServiceSelector labels.Selector) { if services, err := schedulerlisters.GetPodServices(sl, pod); err == nil && len(services) > 0 { return labels.SelectorFromSet(services[0].Spec.Selector) } return nil } </del> // getSelector returns a selector for the services, RCs, RSs, and SSs matching the given pod. func getSelector(pod *v1.Pod, sl corelisters.ServiceLister, cl corelisters.ReplicationControllerLister, rsl appslisters.ReplicaSetLister, ssl appslisters.StatefulSetLister) labels.Selector { labelSet := make(labels.Set)

Discussion:
/sig scheduling /priority important-soon See as an example. /assign
/unassign /help
/assign
/remove-help
Change:
// Free the existing healthCheckNodePort and clear the HealthCheckNodePort field. case neededHealthCheckNodePort && !needsHealthCheckNodePort: glog.Infof("Transition to non LoadBalancer type service or LoadBalancer type service with ExternalTrafficPolicy=Global") <del> err := rs.serviceNodePorts.Release(int(oldHealthCheckNodePort)) if err != nil { glog.Warningf("error releasing service health check %s node port %d: %v", service.Name, oldHealthCheckNodePort, err) return false, errors.NewInternalError(fmt.Errorf("failed to free health check nodePort: %v", err)) } glog.Infof("Freed health check nodePort: %d", oldHealthCheckNodePort) </del> <ins> glog.V(4).Infof("Releasing healthCheckNodePort: %d", oldHealthCheckNodePort) nodePortOp.ReleaseDeferred(int(oldHealthCheckNodePort)) </ins> // Clear the HealthCheckNodePort field. service.Spec.HealthCheckNodePort = 0

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?: /kind bug What happened: healthcheck nodeport allocation doesn't have roll-back, this may lead to nodeport leak. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /sig network /assign Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig network /assign
Could you clarity "roll-back"? It seems that we basically in the same way.
I didn't mean the HealthCheck NodePort release process in . I meant the allocation process in and . Take for example, please see: There is a defer for common NodePorts in : Once fails, the above defer will finally exec. Then the allocated NodePorts will roll-back, i.e. these NodePorts will be released. But the HealthCheck NodePort allocation process doesn't use this roll-back. This will lead to leak. I run a simple test and see the HealthCheck NodePort leak. Will paste the result later.
Testing service manifest, . some simple testing code. See: . Note that I add this error intentionally: kube-apiserver with flag . . We will get below output. This is expected. again. We will get below output. Note the error . That means that when creating service fails at step 3, the NodePort and HealthCheck NodePort should be both released, but the was NOT.
Fortunately, several minute later, the leak was repaired and cleaned up. But anyway, we should release the HealthCheck NodePort when fails. We shouldn't depend on the later repair.
Thanks for tracing down, sent for fixing.
We're having this issue on service deletion. It looks like healthcheck nodeport is not deallocated immediately when deleting the service. This is causing issues for backup and restore of services with heathcheck node port.
Change:
} uuidString := string(uuid.NewUUID()) <del> // UUID string is just hex separated by dashes, which is safe to // throw into regex like this pattern := "^" + uuidString + "$" </del> sentinelName := "__ratcheting_sentinel_field__" sch.Properties[sentinelName] = apiextensionsv1.JSONSchemaProps{ <del> Type:    "string", Pattern: pattern, // Put MaxLength condition inside AllOf since the string_validator // in kube-openapi short circuits upon seeing MaxLength, and we // want both pattern and MaxLength errors AllOf: []apiextensionsv1.JSONSchemaProps{ { MinLength: ptr((int64(1))), // 1 MinLength to prevent empty value from ever being admitted MaxLength: ptr((int64(0))), // 0 MaxLength to prevent non-empty value from ever being admitted }, }, </del> <ins> Type: "string", Enum: []apiextensionsv1.JSON{{ Raw: []byte(`"` + uuidString + `"`), }}, </ins> } for _, v := range myCRD.Spec.Versions {

Discussion:
integration TestRatchetingFunctionality/Enum TestRatchetingFunctionality/MinPropertiesMaxProperties TestRatchetingFunctionality/CELOptionalOldSelf TestRatchetingFunctionality/ TestRatchetingFunctionality/ since 3/8 No response /sig api-machinery
/assign /triage accepted
Change:
printFlockerVolumeSource(volume.VolumeSource.Flocker, w) case volume.VolumeSource.Projected != nil: printProjectedVolumeSource(volume.VolumeSource.Projected, w) <ins> case volume.VolumeSource.CSI != nil: printCSIVolumeSource(volume.VolumeSource.CSI, w) </ins> default: w.Write(LEVEL_1, "<unknown>n") }

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 describe pod xxx not show csi inline volume, it shows <unknow! What you expected to happen: show csi inline volume normally like this ! How to reproduce it (as minimally and precisely as possible): a pod with inline csi volume describe pod xxx not show csi inline volume Anything else we need to know?: Environment: Kubernetes version (use ): 1.14 beta2 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/assign
/sig cli