jiebi/CodeConvo huggingface dataset:
Change:
The IP address in the `EXTERNAL_IP` column is the one that is available on the public internet.  The `CLUSTER_IP` is only available inside your cluster/private cloud network. <ins> Note that on AWS, type `LoadBalancer` creates an ELB, which uses a (long) hostname, not an IP.  It's too long to fit in the standard `kubectl get svc` output, in fact, so you'll need to do `kubectl describe service nginxsvc` to see it.  You'll see something like this: ``` > kubectl describe service nginxsvc ... LoadBalancer Ingress:   a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com ... ``` </ins> ## What's next? [Learn about more Kubernetes features that will help you run containers reliably in production.](production-pods.md)

Discussion:
GCP uses IP addresses, which is shown on an extra line. AWS does not give an IP address. We should show it. GCP: AWS: I'd like to try to do this work.
cc
AWS uses hostnames for load balancers which is why they aren't showing up. The hostname is also pretty long, and I know we've had problems with the width of the kubectl output before. That said, I seem to recall a "--wide" option, and I think you can maybe choose which columns appear? I think it is a useful suggestion, and I think your biggest battle will be to keep the number of columns such that it doesn't normally wrap. Just so you know, I normally do to see the AWS ELB hostname.
Duping this into , we also have an lgtm'd pr out
Change:
printenv | sort echo "--------------------------------------------------------------------------------" <del> if [[ "${E2E_UP,,}" == "true" ]]; then </del> <ins> # We get the Kubernetes tarballs on either cluster creation or when we want to # replace existing ones in a multi-step job (e.g. a cluster upgrade). if [[ "${E2E_UP,,}" == "true" || "${JENKINS_FORCE_GET_TARS:-}" =~ ^[yY]$ ]]; then </ins> if [[ ${KUBE_RUN_FROM_OUTPUT:-} =~ ^[yY]$ ]]; then echo "Found KUBE_RUN_FROM_OUTPUT=y; will use binaries from _output" cp _output/release-tars/kubernetes*.tar.gz . else echo "Pulling binaries from GCS" <del> if [[ $(find . | wc -l) != 1 ]]; then </del> <ins> # In a multi-step job, clean up just the kubernetes build files. # Otherwise, we want a completely empty directory. if [[ "${JENKINS_FORCE_GET_TARS:-}" =~ ^[yY]$ ]]; then rm -rf kubernetes* elif [[ $(find . | wc -l) != 1 ]]; then </ins> echo $PWD not empty, bailing! exit 1 fi

Discussion:
The Jenkins job for GKE upgrade, step 3 (e2e) has been failing since the 4:40pm (PST) run yesterday because of the following DNS problems: This is after the cluster is upgraded.
+cc for triage / suggestions; mentioned as a possibility.
This was almost certainly broken by which was merged at 3:35pm yesterday.
/cc
cc
Yup, my money would be on . Should not be too difficult to track down the bug, given that GCE is working just fine. I'd advise against rolling back if feasible, and rather debug the GKE end of the problem.
Staring at the test it is not clear if anything is wrong with it -- perhaps we need to look at the upgrade code.
I believe that many of the e2e tests begin to fail if DNS isn't working, which to me implies that this is a problem with the test since the failures are isolated to just these two tests. As a side note, I think that this failure is actually correct in the sense that it is catching a legitimate behavioral change between the latest release (0.20.2) and head -- if someone was running code that depended upon the DNS pods to be running in the default namespace and we moved them away then their code would break. In this case, the break was intentional, but it's a behavioral change none the less.
also reported the test failure after upgrade test due to no node is ready in test cluster. We checked it, and found cbr0 is not configured because master never allocate ip range to node, and docker refuse to start.
The code at head selects DNS pods from the system namespace. The code from the 0.20.2 release selects DNS pods from the default namespace. Right now this test is running the e2e test code from the latest release against a cluster that has been upgraded to HEAD.
Thanks for the debugging, all—as Robby said, this catches a behavioral change, which is good. To have the tests pass, we'll want to run the updated tests after an upgrade (this is my next task). I'll mark this as release-note and close it.
Change:
// We used to make the call every 1sec (1 QPS), the goal here is to achieve ~98% traffic reduction when // API server is not healthy. With these parameters, backoff will stop at [30,60) sec interval which is // 0.22 QPS. If we don't backoff for 2min, assume API server is healthy and we reset the backoff. <del> backoffManager:         wait.NewExponentialBackoffManager(800*time.Millisecond, 30*time.Second, 2*time.Minute, 2.0, 1.0, reflectorClock), initConnBackoffManager: wait.NewExponentialBackoffManager(800*time.Millisecond, 30*time.Second, 2*time.Minute, 2.0, 1.0, reflectorClock), clock:                  reflectorClock, watchErrorHandler:      WatchErrorHandler(DefaultWatchErrorHandler), expectedType:           reflect.TypeOf(expectedType), </del> <ins> backoffManager:    wait.NewExponentialBackoffManager(800*time.Millisecond, 30*time.Second, 2*time.Minute, 2.0, 1.0, reflectorClock), clock:             reflectorClock, watchErrorHandler: WatchErrorHandler(DefaultWatchErrorHandler), expectedType:      reflect.TypeOf(expectedType), </ins> } if r.name == "" {

Discussion:
Currently, reflector uses two backoff managers: One is used for initial list call and other for watch call. Imagine following scenaraion when k8s apiserver is under very heavy load: the beginning, reflector spams k8s apiserver (with exponential backoff) with calls until one of them succeeds (due to APF throtling and receiving ) tries to run request and uses separate backoffManager - so again spams k8s apiserver with requests Watch does not succeed during Etcd compaction window (2.5 - 5 minutes usually) at some point it will receive and go back to point 1, spamming k8s apiserver again with List calls (because first backoffManager for List got reseted after 2 minutes of retries for Watch requests) I propose we combine these two backoff managers into one. If we combine these two backoffManagers into one, it will work like this: At the beginning, reflector spams k8s apiserver (still with exponential backoff) with calls until one of them succeeds Tries to make first watch call instantly (as there is no backoff on this path) If it fails, it will makre retries every (30, 60)s If watch request fails all the times during Etcd compaction window it will go back to List call, but already being throttled with (30, 60)s window. /sig scalability
/cc
/assign
I think the proposed solution makes sense to me. Probably before we start, we should to understand why we ended up with two back off managers by looking into PRs touching them. Maybe the code authors had some specific case in mind.
for thoughts too I agree it makes sense, but I don't know the historical context here.
/sig api-machinery
/triage accepted
Change:
# use local dev binaries. # # Assumed vars: <ins> #   KUBE_VERSION </ins> #   KUBE_VERSION_REGEX #   KUBE_CI_VERSION_REGEX # Vars set: <del> #   KUBE_TAR_URL </del> #   KUBE_TAR_HASH #   SERVER_BINARY_TAR_URL #   SERVER_BINARY_TAR_HASH

Discussion:
I suspect we're going through an if/else clause where KUBETARURL isn't defined, and not defaulting it, though the function header seems to indicate it should be set in the callee.
Will take a look.
Is this in Jenkins, or on a local run? The Jenkins push job is borked as well, but it looks like it's for a different reason: Which I'm taking care of in .
Jobs are generating incredibly large log files (300 Megs?) with lots of repeated lines like this: Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 I think this needs to be resolved, since it already caused an out-of-disk in Jenkins.
Okiedokie. Yes, this was my fault. silently expects and to be set in . I the extra expectation that be set, but didn't think about how would then also have to set that. Working on a fix.
(For anyone who cares, culprit is .)
Change:
package gce import ( <ins> "context" </ins> "fmt" "io" "net/http"

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:
"http://metadata.google.internal", "http://169.254.169.254/", "http://metadata.google.internal/", <del> "http://metadata.google.internal/0.1", "http://metadata.google.internal/0.1/", </del> "http://metadata.google.internal/computeMetadata", "http://metadata.google.internal/computeMetadata/v1", // Allowed API versions.

Discussion:
Warning: The v0.1 and v1beta1 metadata server endpoints are deprecated and scheduled for shutdown on September 30, 2020. This test (which runs in most e2e jobs that run on GCE): Schedules a container that runs this: Resulting in a number of legacy metadata endpoints getting hit. To see if this test is going to start failing across all release branches on Sep 30th, we could try disabling the endpoints ahead of time via: In fact and support for expecting different results based on whether is set. My concern is the test expects 200 for some root endpoints, and 403 for disabled endpoints. However the e-mail I received as a GCP customer tells me any legacy endpoints may return 404. I'm inclined to suggest we remove the legacy endpoints from the check, bump the image version, and cherry-pick use of the new image version back to all release-branches. WDYT since you were involved with the earlier PRs /sig auth /sig cloud-provider /provider gcp /sig testing /priority important-soon (I'm tempted to critical-urgent this but it's not drop-everything yet) /milestone v1.20
/kind cleanup
Heyho I wanted to check how it is going? The code freeze is starting 12.11.2020 (about 3-4 weeks from now) and while there is still plenty of time, we want to ensure that each relevant issue has a chance to be considered. As the issue is tagged for 1.20, is it still planned for this release?
Bug Triage here, we're pretty late into code freeze and it doesn't look like there has been much activity recently. I am going to clear the milestone on this issue. /milestone clear
any update here?
Try to cleanup the legacy endpoints in
/milestone v1.21
/reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: )
Reopened this issue. <detailsIn response to : /reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: ) 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 /assign
Change:
// NewNamespaceOptions provides an instance of NamespaceOptions with default values func NewNamespaceOptions(streams genericclioptions.IOStreams) *NamespaceOptions { return &NamespaceOptions{ <del> configFlags: genericclioptions.NewConfigFlags(), </del> <ins> configFlags: genericclioptions.NewConfigFlags(true), </ins> IOStreams: streams, }

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:
import ( "context" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in
Change:
[SERVICE] Flush         5 Grace         120 <del> Log_Level     debug </del> <ins> Log_Level     info </ins> Log_File      /var/log/fluentbit.log Daemon        off Parsers_File  parsers.conf

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 --The default fluent-bit configuration for GCE Windows nodes produces unparsed JSON logs and does not forward container logs. Container log output is produced. fluent-bit on a given windows image. a GCE Windows e2e cluster and view the stackdriver output for pods. Kubernetes version (use ): 1.20+ Cloud provider or hardware configuration: GKE/GCE OS (e.g: ): Windows Kernel (e.g. ): Any version Install tools: fluent-bit 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 windows
Change:
manager.podStoreSynced = alwaysReady var testJob experimental.Job <del> received := make(chan string) </del> <ins> received := make(chan struct{}) </ins> // The update sent through the fakeWatcher should make its way into the workqueue, // and eventually into the syncHandler.

Discussion:
Ran a test executable with more than 20,000 times and no failures. Any hints as to how to get it to show up? I'm running 100 jobs at a time, so my system is stressed already.
I to am unable to reproduce this. I get similar errors if I reduce the timeout at the top of the file. I spent a bit looking at how to rewrite the tests without the timeout, but nothing jumped out at me. Looking at it though, it's really just a 500ms timeout for the test to complete. I'm just going to remove them. Go has a default timeout of 10 minutes. If it's going to pass, it will pass then. If not, Go will give you a nice traceback where it deadlocked.
Change:
} for i := range list.Items { ep := &list.Items[i] <ins> if _, ok := ep.Annotations[resourcelock.LeaderElectionRecordAnnotationKey]; ok { // when there are multiple controller-manager instances, // we observe that it will delete leader-election endpoints after 5min // and cause re-election // so skip the delete here // as leader-election only have endpoints without service continue } </ins> key, err := keyFunc(ep) if err != nil { utilruntime.HandleError(fmt.Errorf("Unable to get key for endpoint %#v", ep))

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG OR Do i miss something important? Kubernetes version (use ): k8s 1.3.5. still exists in 1.6.2 What happened: HA of kube-controller-manager and kube-scheduler is achieved by create endpoint and update it periodically. However, endpoint controller deletes endpoints without corresponding services which is implemented in checkLeftoverEndpoints func: That will result in leader transition. What you expected to happen: checkLeftoverEndpoints func shouldn't delete endpoints used by LeaderElection. How to reproduce it (as minimally and precisely as possible): turn on LeaderElection for kube-controller-manager and kube-scheduler. After five minutes, endpoint controller will delete orphan endpoints. Anything else we need to know: we can add some logic in checkLeftoverEndpoints, for example, not add endpoint in kube-system namespace to queue.
Fixed by
Thanks
Change:
createVolume := "CreateVolume" deleteVolume := "DeleteVolume" <del> publishVolume := "NodePublishVolume" </del> <ins> // publishVolume := "NodePublishVolume" </ins> unpublishVolume := "NodeUnpublishVolume" <del> stageVolume := "NodeStageVolume" </del> <ins> // stageVolume := "NodeStageVolume" </ins> unstageVolume := "NodeUnstageVolume" // These calls are assumed to occur in this order for <del> // each test run. </del> <ins> // each test run. NodeStageVolume and // NodePublishVolume should also be deterministic and // only get called once, but sometimes kubelet calls // both multiple times, which breaks this test // (https://github.com/kubernetes/kubernetes/issues/90250). // Therefore they are temporarily commented out until // that issue is resolved. </ins> deterministicCalls := []string{ createVolume, <del> stageVolume, publishVolume, </del> <ins> // stageVolume, // publishVolume, </ins> unpublishVolume, unstageVolume, deleteVolume,

Discussion:
<!-- 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: Which test(s) are flaking: CSI mock volume storage capacity exhausted, late binding, with topology Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/assign
According to , there really are extra calls to and that shouldn't be there: The current theory is that this might be related to kubelet assuming that a CSI driver does real mounts, something that the mock driver (and potentially other) CSI drivers don't do. A fix for that is pending in That this test runs into this randomly is caused by the test doing more strict checking of CSI calls than other tests. The flaky test failures could be avoided by relaxing that checking, but that won't fix the underlying issue.
I'm not sure I would pin it on the mount check yet. The broader question is why is MountVolume() getting called twice after the first one returns success.
is it due that, the timeout of CSI transaction or call is very low where CSI driver takes more time than this timeout?
Change:
break } } <ins> glog.V(2).Infof("TestPersistentVolumeDeleter pv deleted") } func TestPersistentVolumeBindRace(t *testing.T) { // Test a race binding many claims to a PV that is pre-bound to a specific // PVC. Only this specific PVC should get bound. glog.V(2).Infof("TestPersistentVolumeBindRace started") _, s := framework.RunAMaster(t) defer s.Close() </ins> <del> // test the race between claims and volumes.  ensure only a volume only binds to a single claim. </del> deleteAllEtcdKeys() <ins> testClient, ctrl, watchPV, watchPVC := createClients(t, s) defer watchPV.Stop() defer watchPVC.Stop() ctrl.Run() defer ctrl.Stop() pv := createPV("fake-pv-race", "/tmp/foo", "10G", []api.PersistentVolumeAccessMode{api.ReadWriteOnce}, api.PersistentVolumeReclaimRetain) pvc := createPVC("fake-pvc-race", "5G", []api.PersistentVolumeAccessMode{api.ReadWriteOnce}) </ins> counter := 0 maxClaims := 100 claims := []*api.PersistentVolumeClaim{}

Discussion:
Test failed with and the relevant part of the stack trace is: Logs:
(or anyone), integration tests do not log much and I don't know what's going on in volume controller. Would it be possible to raise integration test log level at least to v=3 (4 preferred)?
what is the status of
can you please take a look?
Increasing integration log level can go into I think. It's probably a good idea to split them into their own job.
Change:
input:    "...foo", expected: "...foo", }, <ins> { name:     "test root directory", input:    "/", expected: "", }, </ins> } for _, test := range tests {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I asked kubectl to extract all the files in a container. Only the names of the top level entries are concerned. How to reproduce it (as minimally and precisely as possible): Just cp the root folder somewhere. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-09-27T17:05:32Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: MaaS + juju OS (e.g. from /etc/os-release): Ubuntu 16.04.5 Kernel (e.g. ): 4.4.0-137-generic -Ubuntu SMP Mon Sep 24 13:14:43 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: juju bundle from canonical
/assign
Hi, - sorry, I didn't notice that this was assigned to you. Would you like me to close my PR?
/sig cli
never mind