jiebi/CodeConvo huggingface dataset:
Change:
if err != nil { glog.Errorf("Failed to execute iptables-restore: %v", err) // Revert new local ports. <del> for k, v := range newLocalPorts { glog.Errorf("Closing local port %s", k.String()) v.Close() } </del> <ins> revertPorts(replacementPortsMap, proxier.portsMap) </ins> return } // Close old local ports and save new ones. for k, v := range proxier.portsMap { <del> if newLocalPorts[k] == nil { </del> <ins> if replacementPortsMap[k] == nil { </ins> v.Close() } } <del> proxier.portsMap = newLocalPorts </del> <ins> proxier.portsMap = replacementPortsMap </ins> // Clean up the older SNAT rule which was directly in POSTROUTING. // TODO(thockin): Remove this for v1.3 or v1.4.

Discussion:
The symptom is the nodeport service is accessible thru hostip:hostport. But the port on host is not occupied. This is exposed by e2e on kubenet. I noticed in the kube- Kube-proxy did open the port. But later, kube-proxy closed the ports upon iptables-restore failure. It never reopen the ports. Hence causing the e2e failure. The code section in question: Not sure why failed. Error messge is not helpful since line 139 is ref:
Also of interest: did it exit with 1? This should be clear from the iptables commands it executed before the commit, which are hopefully in the logs (can you post them). If it's something like a non-exist chain, we should fix that. we retry on exit 1? Handwaving without looking at code: I'd expect something to get requeued, and to reinvoke syncProxyRules once again, in a time frame << test timeout.
Yeah, what was line 139 in the restore output? , Prashanth B wrote:
is No retry though. It is going to catch up in the next sync. So I think no retry for is needed.
FYI Jenkins job:
That iptables restore is 139 lines long, so it's unhappy about the last line? can you hunt ths? , Minhan Xia wrote:
The next sync is whenver the next service/endpoint changes right? Errors during the sync should cause an immediate retry of sync, preferably with backoff. If a service or endpoint never changes we should still recover. Yes we should hunt down the bad line, but it's not the last one right? COMMIT will fail if eg: Even though it's obviously not commit but the tcp/upd thing.
iptables resyncs every 30s, not ideal but in this case I don't expect that to fix the error I meant that we need to root cause it :) , Prashanth B wrote:
But in this case, iptables-restore is going to complain . Not line 2
Hmm
I manually restored the 139 lines above it worked fine - no errors. Even more curious. , Prashanth B wrote:
I also tried to execute the same sequence of iptables-restore. It worked. No errors.

Was this a one-time thing? Were there any other changes in your git repo? , Minhan Xia wrote:
This happened in kubenet suite. Only difference is . I looked at a few runs where e2e failed. This happened 3-4 times over the whole test, but not consecutively. In all-passed runs I checked, this never happened (Maybe I am lucky).
Of , Minhan Xia wrote:
Change:
plugin := plugins[0] fakeMounter := iscsiDiskMounter{ iscsiDisk: &iscsiDisk{ <ins> Iface:  "192.168.1.10:pv0001", </ins> plugin: plugin.(*iscsiPlugin)}, exec: fakeExec, } <del> newIface := "192.168.1.10:pv0001" cloneIface(fakeMounter, newIface) </del> <ins> cloneIface(fakeMounter) </ins> if cmdCount != 4 { t.Errorf("expected 4 CombinedOutput() calls, got %d", cmdCount) }

Discussion:
What happened: When creating a block volume, the iSCSI storage plugin stores volume-related data in different directories: As a result, some data is not cleaned up once the volume is detached: How to reproduce it (as minimally and precisely as possible): These are the objects I used to reproduce this issue: pod- /sig storage CC
/assign
Change:
if servicePort > 0 && !util.IsDNSLabel(name) { return fmt.Errorf("Service creation requested, but an invalid name for a service was provided (%s). Service names must be valid DNS labels.", name) } <ins> ports, err := portsFromString(portSpec) if err != nil { return err } </ins> controller := &api.ReplicationController{ JSONBase: api.JSONBase{ ID: name,

Discussion:
Kubernetes will create replication controller and pods in case of port spec error, e.g. will create 'myNginx'. A following correct spec will fail:
/cc
Change:
sc := &schedulerConfigurator{ // policyfile and algorithm are intentionally undefined. } <del> _, error := sc.Create() if error == nil { </del> <ins> _, err := sc.Create() if err == nil { </ins> t.Fatalf("Expected error message when creating with incomplete configurator.") } }

Discussion:
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
Change:
container, err = strconv.Atoi(pieces[0]) if err != nil { glog.Errorf("Container port is not integer: %s %v", pieces[0], err) <del> continue </del> <ins> return nil, err </ins> } } else { host, err = strconv.Atoi(pieces[0]) if err != nil { glog.Errorf("Host port is not integer: %s %v", pieces[0], err) <del> continue </del> <ins> return nil, err </ins> } container, err = strconv.Atoi(pieces[1]) if err != nil { glog.Errorf("Container port is not integer: %s %v", pieces[1], err) <del> continue </del> <ins> return nil, err </ins> } } if container < 1 { glog.Errorf("Container port is not valid: %d", container) <del> continue </del> <ins> return nil, err </ins> } result = append(result, api.Port{ContainerPort: container, HostPort: host}) } <del> return result </del> <ins> return result, nil </ins> } // RunController creates a new replication controller named 'name' which creates 'replicas' pods running 'image'.

Discussion:
Kubernetes will create replication controller and pods in case of port spec error, e.g. will create 'myNginx'. A following correct spec will fail:
/cc
Change:
} err := o.deleteOrEvictPodsSimple() <del> // TODO: update IsTooManyRequests() when the TooManyRequests(429) error returned from the API server has a non-empty Reason field for i := 1; i <= maxPatchRetry && apierrors.IsTooManyRequests(err); i++ { if i > triesBeforeBackOff { currBackOffPeriod := time.Duration(math.Exp2(float64(i-triesBeforeBackOff))) * backOffPeriod fmt.Fprintf(o.errOut, "Retry in %vn", currBackOffPeriod) o.backOff.Sleep(currBackOffPeriod) } fmt.Fprintf(o.errOut, "Retryingn") err = o.deleteOrEvictPodsSimple() } </del> if err == nil { cmdutil.PrintSuccess(o.mapper, false, o.out, "node", o.nodeInfo.Name, false, "drained") }

Discussion:
In writing some documentation for I noticed some issues with the implementation. I think the simplest user experience is that the command doesn't return until all the user pods are drained off the machine. In particular this means wait until all graceful termination is finished infinitely retry evictions that are rejected due to insufficient PodDisruptionBudget The current implementation does not do this, in particular wait for graceful termination appears to be at 10 sec number of pods, which may be much shorter than the max graceful termination we only retry evictions number of times My suggestion is to change the behavior so that we compute how long to wait for graceful termination, by taking max(grace periods of all pods that we want to delete) (or the value of --grace-period command line argument instead, if that is specified), and wait exactly that amount of time plus a small buffer we retry evictions infinitely WDYT? I think we should do this in 1.5 because the current behavior is very non-obvious.
The problem here is how long should we wait, if the user doesn't specify a timeout. The default timeout used in drain is following how long the reapers have in , , and . Maybe this is not long enough. I can make the changes. Do we still need exponential back off?
To summarize discussion with there are two possible approaches (pseudocode below) 1) Goroutine approach: For each pod P that meets the , do the following: 2) Non-goroutine approach: where "not timed out yet" means you haven't finished waiting max(--grace period argument to kubectl drain, max graceful termination spec across all pods on the node)
Could you please triage this for 1.5 and apply blocker or non-blocker labels as appropriate along with priority.
The PR for this issue is waiting to be merged.
marking this as a release blocker due to being marked as such. Please update if needed cc:
Change:
} } <ins> func TestMissingFromIndex(t *testing.T) { api.ForTesting_ReferencesAllowBlankSelfLinks = true o := testclient.NewObjects(api.Scheme, api.Scheme) if err := testclient.AddObjectsFromPath("../../examples/persistent-volumes/claims/claim-01.yaml", o, api.Scheme); err != nil { t.Fatal(err) } if err := testclient.AddObjectsFromPath("../../examples/persistent-volumes/volumes/local-01.yaml", o, api.Scheme); err != nil { t.Fatal(err) } client := &testclient.Fake{ReactFn: testclient.ObjectReaction(o, latest.RESTMapper)} pv, err := client.PersistentVolumes().Get("any") if err != nil { t.Error("Unexpected error getting PV from client: %v", err) } claim, error := client.PersistentVolumeClaims("ns").Get("any") if error != nil { t.Errorf("Unexpected error getting PVC from client: %v", err) } volumeIndex := NewPersistentVolumeOrderedIndex() mockClient := &mockBinderClient{ volume: pv, claim:  claim, } // the default value of the PV is Pending. // if has previously been processed by the binder, it's status in etcd would be Available. // Only Pending volumes were being indexed and made ready for claims. pv.Status.Phase = api.VolumeAvailable // adds the volume to the index, making the volume available syncVolume(volumeIndex, mockClient, pv) if pv.Status.Phase != api.VolumeAvailable { t.Errorf("Expected phase %s but got %s", api.VolumeBound, pv.Status.Phase) } // an initial sync for a claim will bind it to an unbound volume, triggers state change err = syncClaim(volumeIndex, mockClient, claim) if err != nil { t.Fatalf("Expected Clam to be bound, instead got an error: %+vn", err) } // state change causes another syncClaim to update statuses syncClaim(volumeIndex, mockClient, claim) // claim updated volume's status, causing an update and syncVolume call syncVolume(volumeIndex, mockClient, pv) if pv.Spec.ClaimRef == nil { t.Errorf("Expected ClaimRef but got nil for pv.Status.ClaimRef: %+vn", pv) } if pv.Status.Phase != api.VolumeBound { t.Errorf("Expected phase %s but got %s", api.VolumeBound, pv.Status.Phase) } if claim.Status.Phase != api.ClaimBound { t.Errorf("Expected phase %s but got %s", api.ClaimBound, claim.Status.Phase) } if len(claim.Status.AccessModes) != len(pv.Spec.AccessModes) { t.Errorf("Expected phase %s but got %s", api.ClaimBound, claim.Status.Phase) } if claim.Status.AccessModes[0] != pv.Spec.AccessModes[0] { t.Errorf("Expected access mode %s but got %s", claim.Status.AccessModes[0], pv.Spec.AccessModes[0]) } // pretend the user deleted their claim mockClient.claim = nil syncVolume(volumeIndex, mockClient, pv) if pv.Status.Phase != api.VolumeReleased { t.Errorf("Expected phase %s but got %s", api.VolumeReleased, pv.Status.Phase) } } </ins> type mockBinderClient struct { volume *api.PersistentVolume claim  *api.PersistentVolumeClaim

Discussion:
In case of cluster crash and status recovery, the persistentVolumeClaimBinder would not re-add available volumes to its internal index. Users would not be able to claim those volumes.
This is really bad. I think we should just nix Pending phase and always consider every Available volume for indexing - map lookups are cheap.
Change:
return allErrs } <del> // AccumulateUniquePorts runs an extraction function on each Port of each Container, </del> <ins> // AccumulateUniqueHostPorts extracts each HostPort of each Container, </ins> // accumulating the results and returning an error if any ports conflict. <del> func AccumulateUniquePorts(containers []api.Container, accumulator map[int]bool, extract func(*api.ContainerPort) int) errs.ValidationErrorList { </del> <ins> func AccumulateUniqueHostPorts(containers []api.Container, accumulator *util.StringSet) errs.ValidationErrorList { </ins> allErrs := errs.ValidationErrorList{} for ci, ctr := range containers { cErrs := errs.ValidationErrorList{} for pi := range ctr.Ports { <del> port := extract(&ctr.Ports[pi]) </del> <ins> port := ctr.Ports[pi].HostPort </ins> if port == 0 { continue } <del> if accumulator[port] { cErrs = append(cErrs, errs.NewFieldDuplicate("port", port)) </del> <ins> str := fmt.Sprintf("%d/%s", port, ctr.Ports[pi].Protocol) if accumulator.Has(str) { cErrs = append(cErrs, errs.NewFieldDuplicate("port", str)) </ins> } else { <del> accumulator[port] = true </del> <ins> accumulator.Insert(str) </ins> } } allErrs = append(allErrs, cErrs.PrefixIndex(ci)...)

Discussion:
Pods which use to bind both TCP and UDP sockets to the same port number are rejected with the error: An example pod follows.
Looks like we don't check protocol
The issue was discussed before in , which was closed due to it being low priority.
Hmm, that's 2 pods and the scheduler, this is 2 containers in the same pod and validation at create time. Maybe we should just be more clear about where we stand with hostPort.
Posting here what I posted in the other bug: This can't be worked around when running NFS from a pod. Linux does not allow the NFS port (2049) to be changed, and the Portmap port (111) also cannot be changed. Additionally, you can't separate the UDP from the TCP ports.
Why does NFS need host ports? , Russell Harmon wrote:
Fix is in , Tim Hockin wrote:
Change:
}, } <ins> // Flag errors exit with code 1, however according to the diff // command it means changes were found. // Thus, it should return status code greater than 1. cmd.SetFlagErrorFunc(func(command *cobra.Command, err error) error { cmdutil.CheckDiffErr(cmdutil.UsageErrorf(cmd, err.Error())) return nil }) </ins> usage := "contains the configuration to diff" cmd.Flags().StringVarP(&options.Selector, "selector", "l", options.Selector, "Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2)") cmdutil.AddFilenameOptionFlags(cmd, &options.FilenameOptions, usage)

Discussion:
returns 1 as an exit code: ( keep last exit code in Fish Shell - behaves the same in bash) Based on the help message for diff subcommand: I would expect to have anything returned. In Bash: I found it, troubleshooting misbehavior of a deployment process on my CI server with older kubectl version. That inconsistency might lead to unexpected behavior. Kubernetes version (use ):
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 sig-cli
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-cli 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 cli
/assign
For unsupported flag, it is a general case which handled by cobra lib. By default, we set the exit code as 1 when something wrong with the kubectl command. subCommand never gets a chance to overwrite the exit code in this case.
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/cc Round up in your KEP?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
It still seems to be a problem. /remove-lifecycle stale
Thanks for fixing that!
Change:
# Make /tmp hermetic build --sandbox_tmpfs_path=/tmp <ins> # Ensure that Bazel never runs as root, which can cause unit tests to fail. # This flag requires Bazel 0.5.0+ build --sandbox_fake_username </ins>

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 /sig api-machinery What happened: pull-kubernetes-bazel job is failing See https://k8s- What you expected to happen: test should pass How to reproduce it (as minimally and precisely as possible): bazel test //thirdparty/forked/etcd221/pkg/fileutil:godefault_test
/priority failing-test /area test-infra
/assign
Something weird going on with the prow environment, because this test passes locally with bazel 0.5.2.
Since it is late I will preemptively declare MISSION ACCOMPLISHED from my aircraft carrier and 0.4.5 downgrade workaround (kubernetes/test-infra). I'm sure once we figure things out we'll want to revert this job back to 0.5.2 but in the mean time this should unblock things and the queue should resume merging over the weekend. Expectation is this passes: https://k8s-
I don't know if it's a different issue, but bazel is still failing/flaking all over the place: https://k8s-
/close
Change:
"strings" "testing" <ins> corev1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apiserver/pkg/endpoints/metrics" "k8s.io/component-base/metrics/legacyregistry"

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: for extension API server panics with: Apparently introduces this panic with . What you expected to happen: to do not panic. How to reproduce it (as minimally and precisely as possible): extension API server with - for example the endpoint that the apiserver panics with Anything else we need to know?: Environment: 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:
/kind regression
/sig api-machinery
/assign
cc
Oops - sorry for that. It seems it is basically this comment: that I blindly applied without e2e retesting (the problem seem to be lack of tests, which is a bit surprising because bugs in my previous implementations were caught by tests). ^^ BTW - this has been cherrypicked to previous releases: 16: 17: 18: so it's actually even more critical...
I can file the automated cherry-pick PRs once the PR against the master branch is merged. :)
Reopening - since we need to cherrypick it still.
I now opened the cherry-picks: 16 - 17 - 18 -
Fix and picks are merged
Change:
os.Remove(deviceMountPath) return err } <ins> glog.V(4).Infof("formatting spec %v devicePath %v deviceMountPath %v fs %v with options %+v", spec.Name(), devicePath, deviceMountPath, volumeSource.FSType, options) </ins> } return nil }

Discussion:
Eg: Suspect it's because of:
If this hasn't been seen in 3 months, okay to close?
Yes we fixed it with
Change:
// if you just want remove specific provider, call func RemovePredicateKeyFromAlgoProvider() factory.RemovePredicateKeyFromAlgorithmProviderMap(predicates.CheckNodeConditionPred) <ins> // Fit is determined based on whether a node has Unschedulable spec factory.RegisterMandatoryFitPredicate(predicates.CheckNodeUnschedulablePred, predicates.CheckNodeUnschedulablePredicate) </ins> // Fit is determined based on whether a pod can tolerate all of the node's taints factory.RegisterMandatoryFitPredicate(predicates.PodToleratesNodeTaintsPred, predicates.PodToleratesNodeTaints) <del> // Insert Key "PodToleratesNodeTaints" To All Algorithm Provider </del> <ins> // Insert Key "PodToleratesNodeTaints" and "CheckNodeUnschedulable" To All Algorithm Provider </ins> // The key will insert to all providers which in algorithmProviderMap[] // if you just want insert to specific provider, call func InsertPredicateKeyToAlgoProvider() factory.InsertPredicateKeyToAlgorithmProviderMap(predicates.PodToleratesNodeTaintsPred) <ins> factory.InsertPredicateKeyToAlgorithmProviderMap(predicates.CheckNodeUnschedulablePred) </ins> glog.Warningf("TaintNodesByCondition is enabled, PodToleratesNodeTaints predicate is mandatory") }

Discussion:
DaemonSet should not respect node's field. It's because cluster operators often want system components to be running and ready before workloads run on a given node. OTOH, DaemonSet does respect NoSchedule taints. This behavior is broken by , because DaemonSet share some predicates code with default scheduler.
/assign
Added this to 1.10 milestone, because it's a regression introduced in 1.10.
can you (or a SIG lead) add status/approved-for-milestone please? I'll add the priority. /priority important-soon
how is this use case satisfied by the daemonset controller creating pods and depending on the scheduler to assign them to nodes? having the scheduler ignore the unschedulable field seems nonsensical
I'd like get this as limitation for alpha feature; when upgrade to beta, I'd like to use taint to replace un-scheduable, so DaemonSet pod can tolerate it on-demand.
Escalating to critical-urgent, since we are now in Code Freeze. Please update daily with status, thanks! /priority critical-urgent /remove-priority important-soon
In short term, scheduler can check of pods and ignore bit of nodes for DS pods. Long term, when TaintNodesByCondition is stable, we should replace bit by taint and have DS controller add toleration for the taint when creating pods.
That doesn't seem proper. Making pods behave differently depending on the type of their creating object is very counterintuitive. That seems more reasonable. I'm less certain about auto- tolerations
- indeed there's some work currently to move from to a taint based behaviour, tracked by
Change:
results[i][index], err = priorityConfigs[i].Map(pod, meta, nodeInfo) if err != nil { appendError(err) <del> return </del> <ins> results[i][index].Host = nodes[index].Name </ins> } } }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: A failed Prioritize Map Function caused Scheduler break down. What you expected to happen: Pod remains Pending and describe pod will show errors of failed functions. How to reproduce it (as minimally and precisely as possible): It happens when some prioritize's map functions return with error. Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.6 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
As shown above, if priorityConfigs[i].Map(pod, meta, nodeInfo) returns with error, there will be no chance for results[i + 1] to initialize its value, thus causing panic when calling config.Reduce(pod, meta, nodeNameToInfo, results[i+1])
/sig scheduling
I opened a PR to initialize results with real host name instead of empty string.