jiebi/CodeConvo huggingface dataset:
Change:
import ( "fmt" "io" <del> "testing" </del> "github.com/prometheus/client_golang/prometheus/testutil"

Discussion:
We have many "test only" packages through out the project, containing fixtures, helpers, utilities, etc... These test libraries are not intended for use in production binaries. They often lack rigorous review and sufficient testing for use in production binaries. We should make sure they don't accidentally get pulled in. Strawman proposal, test only packages must import "testing". Blank import is sufficient: Then write a presubmit that fails if we find symbol in the release binary. This approach is trivial and fairly effective although a more sophisticated approach could print a dep chain.
/assign
I hope I will be able to contribute once this gets marked as .
/triage accepted
I think that will be enough a new script or a check in the building scripts /cc since he has experience from the providerless building effort
I got what we want to achieve here but I'm little confused about: If I execute: after adding the import then only it is giving - what do we want to achieve by executing this command exactly? I got what it is doing. I've opened a thread in slack as well:
Hello! Is there anyone working on this issue at the moment? If not and the issue it's still relevant, I would like to work on it if possible. Thank you.
I opened a PR in the meantime, if it's not needed anymore, I can close it.
Change:
case "name": return "name", value, nil case "DesiredState.Host": <del> return "Status.Host", value, nil </del> <ins> return "status.host", value, nil </ins> case "DesiredState.Status": podStatus := PodStatus(value) var internalValue newer.PodPhase newer.Scheme.Convert(&podStatus, &internalValue) <del> return "Status.Phase", string(internalValue), nil </del> <ins> return "status.phase", string(internalValue), nil </ins> default: return "", "", fmt.Errorf("field label not supported: %s", label) }

Discussion:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.
Change:
if err != nil { return starts, fmt.Errorf("Unparseable schedule: %s : %s", sj.Spec.Schedule, err) } var earliestTime time.Time if sj.Status.LastScheduleTime != nil { earliestTime = sj.Status.LastScheduleTime.Time

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): , , Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: bare metal OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: , deployed with Others: What happened: I am using a scheduledjob with . An instance of my job has taken a long time to finish, thus skipping many start times. Ever since, the scheduledjob will not schedule anything new. Controller manager log has: What you expected to happen: I expect the scheduledjob not to be stuck not scheduling anything anymore. With , I expect that it should just re-schedule something as soon as the previously running job has completed. The "Too many missed start times to list" safeguard appears to apply mostly to cases where job concurrency is allowed to avoid creating a lot of jobs in case of timestamp issues. ` How to reproduce it (as minimally and precisely as possible): The issue shows up after about 100 minutes of this running. Anything else do we need to know:
cc
sorry for the long delay in response, there were a few issues solved in later versions of ScheduledJob, can you verify this against latest 1.4.x? I've tried cherry-picking all of the crucial ones, like: and I'll try to verify this on my own as well.

I am still getting the same issue with
thanks for the info, will dig deeper into this one.
Thanks a lot any chance a potential fix could make it in 1.5?
if possible - yes, I'll try to backport it to 1.5
did you look into this? If not, let me know if you want me to pick it up and work on a PR
yeah, go ahead and ping me in the PR.
I just thought of something which might make sense. We've modified the error message to make it more "actionable", and the user can set a deadline to avoid running into this. However, the error message is still only controller level AFAIK and thus not exposed to the user. From the user's perspective, there is not way to tell why the CronJob is not scheduling the next instance. For these reasons, maybe we should also emit an event in the corresponding CronJob? I can send a small PR for this modification.
Change:
MASTER_OS_DISTRIBUTION=${KUBE_MASTER_OS_DISTRIBUTION:-${KUBE_OS_DISTRIBUTION:-gci}} NODE_OS_DISTRIBUTION=${KUBE_NODE_OS_DISTRIBUTION:-${KUBE_OS_DISTRIBUTION:-gci}} CVM_VERSION=container-v1-3-v20160604 <del> GCI_VERSION="gci-dev-54-8743-3-0" </del> <ins> GCI_VERSION="gci-dev-55-8820-0-0" </ins> MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-} MASTER_IMAGE_PROJECT=${KUBE_GCE_MASTER_PROJECT:-google-containers} NODE_IMAGE=${KUBE_GCE_NODE_IMAGE:-${CVM_VERSION}}

Discussion:
The upgraded version of container-vm (gci) has significant performance regressions with localhost networking when compared to its previous versions. is working on making gci kernel fixes to resolve this issue. This issue is meant to track the GCI fix from release 1.4 perspective. The fix for this issue will result in upgrading the gci version pinned to release 1.4 branch. ETA: <TBDStatus: Yellow
can you update the ETA for fixing this issue?
cc for release tracking purposes.
is this a release blocker (why?) or are we aiming for a minor release?
It is a blocker because it causes about 70% drop in throughput which is a significant regression from a k8s on GCP user perspective.
The kernel fix should get merged in GCI kernel today, and hopefully we will be able to release a GCI version tomorrow that includes the fix.
Hmm, I somehow fail to see why a kubernetes release needs to be blocked on a bug fix going into one os the kubernetes release is being deployed on top of, but that's just my opinion
I get your point of view. But, k8s on GCE cannot have serious user-facing issues. The distro is just an implementation detail, but an important one. If we include first-class support for additional distros like ubuntu, debian, etc. in the future, we will have to make the very same priority calls. At the end of the day, the release needs to work for most users in most environments. , Prashanth B wrote:
I think gci related issues shouldn't blocker OSS k8s 1.4 release. I also agreed that k8s on GCE cannot have serious user-facing issues, but that can be resolved by reverting the changes of making GCE node on GCI default. I am not suggesting that we do that now, but I do suggest we have the summary of the entire issue (not only this particular one) on GCI on node, and deeply understand the risk, then make the final decision. On another hand, we are still planning to enable GCI on node default between 1.4 and 1.5 time framework. cc/
Change:
if err := kl.initializeModules(); err != nil { kl.recorder.Eventf(kl.nodeRef, v1.EventTypeWarning, events.KubeletSetupFailed, err.Error()) <del> glog.Error(err) kl.runtimeState.setInitError(err) </del> <ins> glog.Fatal(err) </ins> } // Start volume manager

Discussion:
In our k8s cluster, a node's status is NotReady, and we checked the kubelet's log, that repeated "skipping pod synchronization" every 5 minutes: I found the code where printing those logs, in the syscLoop function. if runtimeState has error, kubelet will get into endless loop, and will print "skipping pod synchronization" every five minutes. In our case, the node got an error when startup, in the function initializeModules, which called our cloud provider to get node info, because the call returned an error, kubelet set the error to runtimeState, and ran syscLoop next, going to endless loop. I think there is a problem here: Startup function "initializeModules" encountered an error like "failed get node info", which is rarely, kubelet should exit its process and it will be restarted by systemd successfully. Restarting kubelet is more reaonable than printing error log in the endless loop, Restarting event can be mornitored easily, but the admin can hardly detect the endless loop.
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. Prevent issues from auto-closing with an comment. 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 stale
/remove-lifecycle rotten
Change:
for _, term := range terms { ee.sum += term } <del> t.Logf("Adding expectation %#+v", ee) </del> <ins> t.Logf("At idx=%v, adding expectation of buckets=%#+v, upperBounds=%#+v, sum=%v, count=%v", whIdx, ee.buckets, ee.upperBounds, ee.sum, ee.count) </ins> expectations = append(expectations, ee) } // Do the planned calls on ObserveWithWeight, in randomized order

Discussion:
pull-kubernetes-unit see title 8/17? ref No response /sig instrumentation
/triage accepted /assign
an example flake in of sig-release/master-blocking test grid. (It flakes a few times, and it is not a blocker.)
/cc still flake
I tested it locally, and it did reproduce the error. I'll take a look at this problem.
I looked into this part of the code. The problem should be the loss of precision. as the denominator of is too large, that is to say, occasionally satisfies the condition( ≈0.16%), and the allowed precision error is too small. So, occasionally this test flakes. I modified the code and printed out the results of in the log(It can be seen that the value is greater than ): see stress test result details from the . I don't know much about this, how did you decide to use as the denominator? Maybe we can adjust the precision error( for example 1e-14 -1e-13 or other value)? Can you take a look? FYI: In the prometheus histogram test , this error value is set to
I do not recall exactly how I arrived at the limit of 1e-14. That is about 46.5 bits, which should be well within the accuracy of a . To get this test passing, I have increased the limit by a factor of 10 (in ), based on the relative errors reported above.
Change:
existed = true } <del> return address.Address, existed, nil </del> <ins> addr, err := gce.GetRegionAddress(name, region) if err != nil { return "", false, fmt.Errorf("error getting static IP address: %v", err) } return addr.Address, existed, nil </ins> }

Discussion:
/kind bug What happened: Services of type LoadBalancer (GCE) with IP addresses promoted to static (by user or by orphan) cause the service controller to panic. The constant panicking will cause a reboot loop of the pod. How to reproduce it (as minimally and precisely as possible): a service on GCP it the GCP Console, promote the IP address of the LB to static and set the name to the loadBalancerName which is the same name as the forwarding rule. Environment: Kubernetes version: 1.7.0 AND 1.7.1 Cloud provider or hardware configuration: GCE Symptoms -controller-manager crash loops on the master. Mitigation** Option 1: Build your own version of branch for the master. Only the kube-controller-manager image needs to be updated. Option 2: For all affected services, set the field to the known external IP address. Steps: list of reserved IPs gcloud compute addresses list NAME REGION ADDRESS STATUS us-central1 35.35.35.35 INUSE list of all Services of type LoadBalancer kubectl get svc --all-namespaces | grep "LoadBalancer" default my-service LoadBalancer 10.0.99.201 35.35.35.35 80:/TCP,443:/TCP 58m each service of type LoadBalancer with an IP that's reserved (in the list above), continue to next step. the service's field equal to the known IP. Example_ apiVersion: v1 kind: Service metadata: creationTimestamp: 2017-07-13T00:09:31Z labels: app: echo name: my-service namespace: default resourceVersion: "" selfLink: /api/v1/namespaces/default/services/my-service uid: -675f-11e7-bee2- spec: clusterIP: 10.0.99.201 externalTrafficPolicy: Cluster loadBalancerIP: 35.35.35.35 <------- Field set to below. ports: name: port-1 nodePort: port: 80 protocol: TCP targetPort: 80 name: port-2 nodePort: port: 443 protocol: TCP targetPort: 443 selector: app: echo sessionAffinity: ClientIP type: LoadBalancer status: loadBalancer: ingress: ip: 35.35.35.35
/sig network /assign /area platform/gce
cc
Change:
----------------------------------------- This example requires a running Kubernetes cluster.  See the [Getting Started guides](../../../docs/getting-started-guides/) for how to get started. <del> Change to the `<kubernetes>/examples/limitrange` directory if you're not already there. </del> <ins> Change to the `<kubernetes>` directory if you're not already there. </ins> Step 1: Create a namespace -----------------------------------------

Discussion:
Since resource QoS is implemented, limitrange also supports request constraint, we can add an example for that.
cc
Change:
kernel=$(uname -s) case "${kernel}" in Linux) <del> curl --retry 10 -L -o cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 curl --retry 10 -L -o cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 </del> <ins> curl --retry 10 -L -o cfssl https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 curl --retry 10 -L -o cfssljson https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 </ins> ;; Darwin) <del> curl --retry 10 -L -o cfssl https://pkg.cfssl.org/R1.2/cfssl_darwin-amd64 curl --retry 10 -L -o cfssljson https://pkg.cfssl.org/R1.2/cfssljson_darwin-amd64 </del> <ins> curl --retry 10 -L -o cfssl https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_darwin_amd64 curl --retry 10 -L -o cfssljson https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_darwin_amd64 </ins> ;; *) echo "Unknown, unsupported platform: ${kernel}." >&2

Discussion:
Looks like the hardcoded URL - is not working anymore and returns: Having said that - installation from works.
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
looks like we have a bunch of locations to fix: ,kubernetes/test-infra,kubernetes/website Looks like this was their plan all along: They have yum/apt repos in:
/assign
Sorry that page is offline, we're looking at it internally () It's also worth nothing that (http does work) only has versions from 2018 and prior (I see 1.2.0 is being used here), newer + current versions are available at , but i'm not sure if there's changes between versions that would break your workflows. (Unfortunately we haven't gotten around to publishing debs for cfssl on yet.)
Seems like "" can't be used but "" works fine. Since the version 1.2.0 is old, I replace them with latest 1.5.0 installation from in Is that ok?
yes, 1.5.0 will do. thanks!
/sig testing
Change:
return err } <del> if err := balancer.DeleteTCPLoadBalancer(service.JSONBase.ID, zone); err != nil { </del> <ins> if err := balancer.DeleteTCPLoadBalancer(service.JSONBase.ID, zone.Region); err != nil { </ins> return err }

Discussion:
Comments that the PR bot adds solely to trigger email notification of a label change, should be immediately deleted by the bot after it adds them. I have no idea what team to assign this to... cc/
, David Oppenheimer wrote:
(Motivation, of course, is to avoid having PR threads that are 90% bot comments...)
should really be an issue over in that's where (some of) the bots live. Lets make a list of which comments we want deleted immediately. [x] Label size. [x] Needs rebase. [x] test this stale CI [x] test this pending CI [x] PR changed after LGTM, removing LGTM. [x] Comment about blocking based on the paths touched (old docs) [x] unapproved cherrypick comment [x] cherrypicks must set a milestone [x] ok to test from bot I don't want to make it all comments. There are way too many times people have asked me "Why did the bot add 'do-not-merge'?" and I can just link them the comment 2 lines above which tells exactly why....
"Test this" with an issue is also useful, isn't it? On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
OK to test Add to whitelist On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
I was envisioning deleting the by the bot. (every 48 hours after LGTM, when retesting right before merge) not those by users (with an issue) After LGTM the bot will add , that one I can remove. The request to comes from the jenkins bot. And in that I am clueless...
any interest in a review (I'm trying to not just self merge all my own bot changes). This deleted hundreds and hundreds of comments.
Looks like reviewed it since your last message:

The contains instructions for downloading kubectl. The doesn't contain these instructions but it should if it's now the recommended way of running Kubernetes locally.
+1 Just ran into this.
cc
By the way, we encourage anyone to propose improvements/fixes to docs. You can do so pretty easily by clicking the pencil icon in the top right corner of every page of
kubectl download instructions to the guide in
Change:
o.Record = cmdutil.GetRecordFlag(cmd) o.ChangeCause = f.Command(cmd, false) o.PrintObject = f.PrintObject <ins> o.Local = cmdutil.GetFlagBool(cmd, "local") </ins> o.DryRun = cmdutil.GetDryRunFlag(cmd) o.Output = cmdutil.GetFlagString(cmd, "output") o.ResolveImage = f.ResolveImage

Discussion:
It tries to contact the api server for the discovery docs and fails because no api server is running. Could first look in its local cache if it's passed --local?
I think here has similar meaning as , it will not contact api-server to do real patch, but it will fetch the resource from api-server. What you mean look in it's local cache? to find the resource in local cache? I think you have specified the resource in your command line.
Use of --local flag should completely eliminate communication with api-server I have sent a PR which should fix this issue A command like kubectl set image --local -f busybox=busybox:1.26 -o yaml should load the local yaml file and print out the patched version (image should get updated to busybox:1.26) in yaml format on the screen. With the submitted patch such behavior is achived
Change:
// was allocated. _, _, err := m.containerMap.GetContainerRef(containerID) if err == nil { <del> klog.InfoS("ReconcileState: ignoring terminated container", "pod", klog.KObj(pod), "containerID", containerID) </del> <ins> klog.V(4).InfoS("ReconcileState: ignoring terminated container", "pod", klog.KObj(pod), "containerID", containerID) </ins> } m.Unlock() continue

Discussion:
kubernetes 1.19.2 seeing tons of these, feels like something that should be debug or info ... not really actionable or something that it should warn about ? /sig node
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
I am also seeing this same issue what's odd is that I cannot find the container it's looking for which is probably why its giving this message, so my question would be why is it looking for this container ID?
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
/lifecycle frozen
I agree this should be lower than warning... /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I agree this should be lower than warning... /help 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
I think all InfoS messages under the should be moved to debug messages because it flood the log when the CPU manager enabled with the static policy.
/assign
Change:
needCreateResource["memory"] = *resource.NewQuantity(int64((ratio-memFraction)*float64(memAllocatableVal)), resource.BinarySI) <del> testutils.StartPods(cs, 1, ns, "priority-balanced-mem-"+node.Name, </del> <ins> err := testutils.StartPods(cs, 1, ns, "priority-balanced-mem-"+node.Name, </ins> *initPausePod(f, pausePodConfig{ Name:   "", Labels: balancePodLabel,

Discussion:
Chronically failing test. Perhaps covers deprecated behavior? /sig scalability /assign
shows up in
/sig scheduling is one of scheduling e2e test.
/assign I'll check this one.
According to the log, the balanced pods were not created by scheduler, the cpu/mem usage was unchanged.
This test failing every other run. Fix or disable? Blocking 1.7?
similar to , move to 1.8, but I'll still working on that.