jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> func TestProxyUpdateDeleteUpdate(t *testing.T) { lb := NewLoadBalancerRR() lb.OnUpdate([]api.Endpoints{{JSONBase: api.JSONBase{ID: "echo"}, Endpoints: []string{net.JoinHostPort("127.0.0.1", port)}}}) p := NewProxier(lb) proxyPort, err := p.addServiceOnUnusedPort("echo") if err != nil { t.Fatalf("error adding new service: %#v", err) } conn, err := net.Dial("tcp", net.JoinHostPort("127.0.0.1", proxyPort)) if err != nil { t.Fatalf("error connecting to proxy: %v", err) } conn.Close() p.OnUpdate([]api.Service{}) if err := waitForClosedPort(p, proxyPort); err != nil { t.Fatalf(err.Error()) } proxyPortNum, _ := strconv.Atoi(proxyPort) p.OnUpdate([]api.Service{ {JSONBase: api.JSONBase{ID: "echo"}, Port: proxyPortNum}, }) testEchoConnection(t, "127.0.0.1", proxyPort) } </ins> func TestProxyUpdatePort(t *testing.T) { lb := NewLoadBalancerRR() lb.OnUpdate([]api.Endpoints{{JSONBase: api.JSONBase{ID: "echo"}, Endpoints: []string{net.JoinHostPort("127.0.0.1", port)}}})

Discussion:
if you delete a service and restart it the port is no longer accessible To reproduce: 1) start a pod 2) start a service All works fine port is assigned - traffic flows 3) delete service 4) start service the port is now not assigned Here are sample configs: pod: Service:
I thought this was a known issue, but I could not find another issue on the same topic. Note that all containers started after the first instance of the service was created will have environment variables referring to that instance and won't see environment variables referring to the new instance until they restart. This is a fundamental shortcoming of the current approach.
I understand what you just replied but that is not the issue here. The problem is that when you delete a service , no other service can resuse that port successfully. The port is removed from a netstat listing. When a new service tries to use that port it gets allocated but you can not communicate to the pod through it. It is hosed until I re-install the cluster. (I have not tried rebooting the cluster) BTW this is a bug not a design issue.
Ah. The previous issue I was thinking of was . It sounds like the issue hasn't been completely resolved.
I will take a look at this today.
Sorry for the problem, has the fix. --brendan
Thanks! On Aug 19, 2014, at 2:26 PM, brendandburns wrote:
Change:
CONTAINERIZED_MOUNTER_HOME="${KUBE_HOME}/containerized_mounter" PV_RECYCLER_OVERRIDE_TEMPLATE="${KUBE_HOME}/kube-manifests/kubernetes/pv-recycler-template.yaml" <ins> log-start 'SetPythonVersion' if [[ "$(python -V 2>&1)" =~ "Python 2" ]]; then # found python2, just use that PYTHON="python" elif [[ -f "/usr/bin/python2.7" ]]; then # System python not defaulted to python 2 but using 2.7 during migration PYTHON="/usr/bin/python2.7" else # No python2 either by default, let's see if we can find python3 PYTHON="python3" if ! command -v ${PYTHON} >/dev/null 2>&1; then echo "ERROR Python not found. Aborting." exit 2 fi fi echo "Version :  $(${PYTHON} -V 2>&1)" log-end 'SetPythonVersion' </ins> log-start 'SourceKubeEnv' if [[ ! -e "${KUBE_HOME}/kube-env" ]]; then echo "The ${KUBE_HOME}/kube-env file does not exist!! Terminate cluster initialization."

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gce-device-plugin-gpu Cluster up Apr 23 8:30PM PDT Taken from: From a , there are supposed to be three worker/minion nodes set up as well. Started failing after -- so maybe related to ? /cc /sig testing More examples of failing runs: /priority critical-urgent (this is a job on the release/master-blocking board)
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
It uses image gke-1134-gke-rc5-cos-69--138-0-v190320-pre-nvda-gpu as node image kubekins-e2e image is built from Base image is bootstrap image is built from with debian:buster and install python3.
The node image gke-1134-gke-rc5-cos-69--138-0-v190320-pre-nvda-gpu has no python3. We need to upgrade it.
Thanks for catching this and sending revert. Separately, we should definitely upgrade that image, cos-69 is super old and not supported anymore: /cc regarding GPU image
Change:
RUN yum -y install /usr/bin/ps nfs-utils && yum clean all RUN mkdir -p /exports ADD run_nfs.sh /usr/local/bin/ <del> ADD index.html /exports/index.html RUN chmod 644 /exports/index.html </del> <ins> ADD index.html /tmp/index.html RUN chmod 644 /tmp/index.html </ins> <del> EXPOSE 2049/tcp </del> <ins> # expose mountd 20048/tcp and nfsd 2049/tcp EXPOSE 2049/tcp 20048/tcp </ins> <del> ENTRYPOINT ["/usr/local/bin/run_nfs.sh", "/exports"] </del> <ins> ENTRYPOINT ["/usr/local/bin/run_nfs.sh", "/exports", "/"] </ins>

Discussion:
GCE minion VM OS version is The nfs server image and hits with the following dump stack
Image version now exists!
thanks!
Change:
var validationErrors []error for _, priority := range policy.Priorities { <del> if priority.Weight <= 0 { validationErrors = append(validationErrors, fmt.Errorf("Priority %s should have a positive weight applied to it", priority.Name)) </del> <ins> if priority.Weight <= 0 || priority.Weight >= schedulerapi.MaxWeight { validationErrors = append(validationErrors, fmt.Errorf("Priority %s should have a positive weight applied to it or it has overflown", priority.Name)) </ins> } }

Discussion:
Weight is an int (see ). Priority can take the range 1-10. Total priority for a node is sum of weight  priority for each priority function, and the sum is accumulated into an int (see ). So obviously the total priority can overflow if someone sets the weight(s) too high. The weights of all priority functions are compiled in (or specified in config file), so we can check to make sure maximum total priority can't overflow an int (take sum over all priority functions of 10  weight of that priority function, and make sure that's smaller than int(MaxUint 1) which according to StackOverflow is the way to find out what is max int (math package has max Int32, Int64, etc. but not max Int). Note that scheduler extender is OK because although the policy runs in a separate process, the weight is specified in scheduler config file (ExtenderConfig struct) and the priority is bounded 1-10 as usual.
We really should also make "score" be an abstract datatype rather than a raw int that is manipulated directly, so we can do things like make sure it is in the range 1-10 (or 0-10 if that's what we want); today the range is inconistent (we say 1-10, but sometimes use 0; probably we should change it to 0-9..).
I volunteer myself to do this.
I think we can check weight overflow in after we get all PriorityConfig. what do you think about this?
As for "score" I think we can use
Fixed by - closing.
Tim that PR was closed, not merged. I don't think this is fixed yet.
whoops, good catch, just removing milestone then. There was a shift that happened yesterday where a bunch of items suddenly came into the 1.6 query.
do we still want this fixed? I can re-pick this.
AFAIK it's still broken. cc/
Ok, I will open a PR tomorrow.
Change:
} } <ins> func TestIsWorkingClearedAfterForgetPodWorkers(t *testing.T) { podWorkers, _ := createPodWorkers() numPods := 20 for i := 0; i < numPods; i++ { podWorkers.UpdatePod(&UpdatePodOptions{ Pod:        newPod(strconv.Itoa(i), "name"), UpdateType: kubetypes.SyncPodUpdate, }) } drainWorkers(podWorkers, numPods) if len(podWorkers.podUpdates) != numPods { t.Errorf("Incorrect number of open channels %v", len(podWorkers.podUpdates)) } podWorkers.ForgetNonExistingPodWorkers(map[types.UID]sets.Empty{}) if len(podWorkers.podUpdates) != 0 { t.Errorf("Incorrect number of open channels %v", len(podWorkers.podUpdates)) } if len(podWorkers.isWorking) != 0 { t.Errorf("Incorrect number of isWorking %v", len(podWorkers.isWorking)) } } </ins> type simpleFakeKubelet struct { pod       *v1.Pod mirrorPod *v1.Pod

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 --As the p.isWorking won't be cleared while pod was deleted, so while creating or deleting pods repeatedly, length of p.isWorking keep increasing length of p.isWorking does not keep increasing creating or deleting pods repeatedly Kubernetes version (use ): 1.19.4 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:
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 node
/assign
Change:
failureThreshold: 5 readinessProbe: httpGet: <del> path: /health port: 8080 </del> <ins> path: /ready port: 8181 </ins> scheme: HTTP securityContext: allowPrivilegeEscalation: false

Discussion:
Which jobs are failing: Multiple jobs on . Which test(s) are failing: on the following jobs: Since when has it been failing: Since 5/17. Testgrid links: See above. Reason for failure: All the failures mentioned above seem to have to have the same root cause, namely failure while waiting for CoreDNS to be ready. Example: /sig testing /priority critical-urgent /kind failing test /milestone v1.15 /cc
Some of this (possible all of it) is due to , which is dependent on being merged.
/sig cluster-lifecycle
Not the gce jobs thoght. Only the kinder job. So the gce jobs are failing with a problem outside of kubeadm/kinder but possibly still related to the corefile plugin change
/assign (At kubecon this week)
The gce failures appear to show the same behavior, but with kube-up instead of kubeadm. I.e. it appears that kube-up may also be retaining old configs when upgrading/downgrading. If thats true, then we may need to integrate the migration tools into kube-up as well.
I have opened which aims to fix all the failing tests except , which will be fixed via
Great job so far and Would it be possible to ask for the open PRs to be merged and/or a solution found soon? We have these tests failing for quite some time and code freeze coming up in the next days. Thank you in advance for your efforts!
thanks for the heads up. let me know if you don't have the time for the refactor that i requested and i can try to take over there. the alternative is to rollback the coredns version which i assume is not ideal, due to a variety of fixes in the new version.
is there any more work planned for this issue? I see that some of the kinder jobs are still failing after merged:
merging and will resolve and close this issue.
Thank you for the update !
updates: kinder tests were fixed via
/unassign i was here for: it's a bit flaky (which is due to the tooling), but green.
Since and we're moved to 1.16, and we're waiting for to merge, can we move this issue to 1.16?
? is that the right PR?

Good catch, I meant
The GCE test failures were fixed by and /close
Closing this issue. <detailsIn response to : The GCE test failures were fixed by and /close 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:
} item, ok := f.items[id] if !ok { <del> // Item may have been deleted subsequently. </del> <ins> // This should never happen klog.Errorf("Inconceivable! %q was in f.queue but not f.items; ignoring.", id) </ins> continue } delete(f.items, id)

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: In reviewing another PR, I noticed incorrect commentary and code. The primary offense is at , where a comment asserts (incorrectly) that a key can be present in but not and the code removes a key from without ensuring it is absent from . The only saving grace is that this code is actually unreachable (as also noted in the comment). I think it would be better to fix the comment and in this unreachable situation, than to violate an invariant that is critical to other code in this file. also contemplates the possibility that a key can be in and absent from . What you expected to happen: I expected there to be no comments or code that contemplate violations of the invariant at How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): current branch 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:
Sorry, I should have noticed this in my earlier pass over this code.
Agreed. Was discussing this with at
We discussed this one, Mike will send PR, Daniel will review.
Change:
// Do not return error if the container does not exist if !libdocker.IsContainerNotFoundError(err) { errList = append(errList, err) <ins> } else { // remove the checkpoint for any sandbox that is not found in the runtime ds.checkpointHandler.RemoveCheckpoint(podSandboxID) </ins> } } return utilerrors.NewAggregate(errList)

Discussion:
/kind bug What happened: the kubelet keeps attempting to gc containers from dockershim checkpoint files. if the container is no longer present, we keep attempting to gc it because the file is never removed from checkpoint. What you expected to happen: checkpoint should not leak.
/sig node
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" pkgruntime "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/runtime" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apimachinery/pkg/watch" "k8s.io/client-go/tools/cache"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Report Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-10-10T18:19:49Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.9", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-10-20T20:37:18Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): Local: El Capitan, Remote: GCI Kernel (e.g. ): Local: Darwin ... 15.6.0 Darwin Kernel Version 15.6.0: Thu Sep 1 15:01:16 PDT 2016; root:xnu-3248.60.11~2/RELEASEX8664 x86_64 Install tools: gcloud Others: n/a What happened: Provisioned 3 clusters each in different regions (us-central1, asia-east1, europe-west1). Each cluster is in 2 zones (w/ gcloud --zone... --additional-zones...) Provisioned Federation API Server and Controller (1.4.4) based on Verified clusters were ready. Provisioned federated service & deployed backends into each of the cluster. Verified the federated services were created, and all of the regional LB were created, and verified all the LB IPs were working w/ direct requests. DNS provider updated DNS w/ most of the service/zone CNAME records. But A records did not complete. Further investigation for the log points to multiple entries in rrdata w/ the same IP due to the multi-zone deployment: I1029 19:24:24. 1 ] Have recordset <(clouddns) "buttonmasher-" type=CNAME rrdatas=["buttonmasher-"] ttl=180.

Need recordset <(clouddns) "buttonmasher-" type=A rrdatas=["130.211.203.196" "130.211.203.196"] ttl=180I1029 19:24:24. 1 ] Existing recordset <(clouddns) "buttonmasher-" type=CNAME rrdatas=["buttonmasher-"] ttl=180is not equivalent to needed recordset <(clouddns) "buttonmasher-" type=A rrdatas=["130.211.203.196" "130.211.203.196"] ttl=180, removing existing and adding needed. After creating the clusters w/ only one zone, the DNS provider worked properly. What you expected to happen: Cloud DNS Provider should update the DNS record properly w/ multi-zone clusters. How to reproduce it (as minimally and precisely as possible): 3 x multi-zone clusters Federation API Server and Controller clusters in to federation federated service and backends Anything else do we need to know: Using GKE and Cloud DNS
/cc
Also hit this. Any workarounds?
Sorry, no direct workarounds available yet. You could convert your multi-zone clusters into multiple single-zone clusters, and federate all of those.
FYI, although I'm sure you're aware - also affects AWS multi AZ clusters (1.6.2)
This seems bad. I'll try to take a look into it.
Fixed by
Change:
return &priorityMetadata{ podLimits:               getResourceLimits(pod), podSelector:             getSelector(pod, pmf.serviceLister, pmf.controllerLister, pmf.replicaSetLister, pmf.statefulSetLister), <del> controllerRef:           metav1.GetControllerOf(pod), </del> podFirstServiceSelector: getFirstServiceSelector(pod, pmf.serviceLister), podTopologySpreadMap:    tpSpreadMap, }

Discussion:
/sig scheduling /priority important-soon See as an example. Part of This shouldn't need a PostFilter Plugin, it is not worth caching the result of metav1.GetControllerOf. /assign
Change:
BearerToken:      stringptr(""), Impersonate:      stringptr(""), ImpersonateGroup: &impersonateGroup, <ins> usePersistentConfig: usePersistentConfig, </ins> } }

Discussion:
/kind bug What happened: takes ~11 seconds when there are thousands of CRDs and is around 28KiB. logs the following message once per resource: Removing unnecessary entries from reduces the runtime by around ten seconds. What you expected to happen: only parses once, and therefore doesn't run unnecessarily slowly. How to reproduce it (as minimally and precisely as possible): shows the config being loaded multiple times (assuming you have multiple pods in the current cluster). Alternatively, add 10-15 clusters to and create ~3000 of a cheap resource (eg custom resources or empty config maps). Run on this resource and observe that it is unnecessarily slow. Anything else we need to know?: I've created a CPU profile using the latest CI build of kubectl, which shows ~12 seconds being spent in . Environment: Kubernetes version (use ): v1.12.1 (also Cloud provider or hardware configuration: GKE or minikube --vm-driver=none OS (e.g. from /etc/os-release): Debian Buster-like Kernel (e.g. ): 4.17.0
/sig cli
/assign
Same problem here. I have less resources but more contexts in my kubeconfig file. With 90 pods and ~300 contexts in the kubeconfig it also takes ~10 seconds for a simple kubectl get pods Note: I tried it with kubectl: 1.11.0, 1.12. With kubectl 1.10.5 the kubeconfig was loaded only once.
I'm unable to reproduce this as of the latest master. My kubeconfig is only loaded 4 times, no matter how many resources are loaded.
When I try a kubectl v1.13.0-alpha.3 against unfortunately a 1.9.11 Kubernetes Cluster I still have the problem: `
Maybe the bug is Linux-only? Presumably the kubeconfig location is different on different platforms, so maybe it has a different code path. I can repro on latest master:
I filed to fixed this. You can try to help validate it. Thanks.
Works for me, thanks!
Change:
package cache import ( <ins> "fmt" </ins> "reflect" "testing"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently some unit tests in pkg/scheduler is not organized as Use subtests can make it easier to find out which case fails and leverage benefit of parallelism . Why is this needed: Follow Go test practice.
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
/remove-kind feature /kind cleanup /sig scheduling /assign
Change:
ENV DO_NOT_INSTALL_CATCH_ALL_CONFIG true RUN apt-get -q update &&  <del> apt-get install -y curl &&  apt-get install -y gcc &&  apt-get install -y make &&  </del> <ins> apt-get install -y curl ca-certificates gcc make bash &&  apt-get install -y --reinstall lsb-base lsb-release &&  echo "Installing logging agent" &&  curl -sSL https://dl.google.com/cloudagents/install-logging-agent.sh | bash &&  /usr/sbin/google-fluentd-gem install fluent-plugin-record-reformer -v 0.8.1  &&  /usr/sbin/google-fluentd-gem install fluent-plugin-systemd -v 0.0.3 &&  apt-get remove -y gcc make &&  apt-get autoremove -y &&  </ins> apt-get clean &&  <del> rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* &&  curl -s https://dl.google.com/cloudagents/install-logging-agent.sh | bash # Install the record reformer and systemd plugins. RUN /usr/sbin/google-fluentd-gem install fluent-plugin-record-reformer -v 0.8.1 RUN /usr/sbin/google-fluentd-gem install fluent-plugin-systemd -v 0.0.3 # Remove the misleading log file that gets generated when the agent is installed RUN rm -rf /var/log/google-fluentd </del> <ins> rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*  /opt/google-fluentd/embedded/share/doc  /opt/google-fluentd/embedded/share/gtk-doc  /opt/google-fluentd/embedded/lib/postgresql  /opt/google-fluentd/embedded/bin/postgres  /opt/google-fluentd/embedded/share/postgresql  /var/log/google-fluentd </ins> # Copy the Fluentd configuration files for logging Docker container logs. # Either configuration file can be used by specifying `-c <file>` as a command

Discussion:
It's 400+mb and we need to pull it on every node. This leads to a lot of image pulling flake (), and also gets very expensive in some countries where bandwidth is sold at a premium. We took a stab at halving the size with: , but then realized that we were using an unsupported base image We tried to optimize to ~300Mb by building a smaller ubuntu:15 base, but that's still huge. Every other mandatory system daemon is built on busybox and so takes ~10Mb.
I can try again now that the agent supports
Newer Docker images using the spec from the official repository are based on AlpineLinux and are around ~38MB:
Change:
// TestErrConnKilledHTTP2 check if HTTP/2 connection is not closed when an HTTP handler panics // The net/http library recovers the panic and sends an HTTP/2 RST_STREAM. func TestErrConnKilledHTTP2(t *testing.T) { <del> readStdErr, cleanUp, err := captureStdErr() if err != nil { t.Fatalf("unable to setup the test, err %v", err) } defer cleanUp() </del> <ins> var buf bytes.Buffer klog.SetOutput(&buf) klog.LogToStderr(false) defer klog.LogToStderr(true) </ins> handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // this error must be ignored by the WithPanicRecovery handler // it is thrown by WithTimeoutForNonLongRunningRequests handler when a response has been already sent to the client and the handler timed out

Discussion:
/sig api-machinery /kind bug /priority important-soon
It seems something is racing writhing the logs ? cc:
/cc /triage accepted
Failed with this: pull-kubernetes-unit
this looks like a test-only race where the test overwriting the global os.Stderr in order to capture error output races with an async attempt to log to it from another test in the same package
which still needs to be fixed
It seems to me that this bug can not be fixed with as it is, namely used without a logger object or even a . The smallest tweak that occurs to me would be to add an option to to add an output destination, and later remove that addition. Thus, a test could add logging to its own buffer for the duration of running the code under test.
This may be similar to . How can I reproduce this issue?