jiebi/CodeConvo huggingface dataset:
Change:
// // // <del> // // // // // </del> // This must be line #50. var _ = ginkgo.Describe("e2e", func() {

Discussion:
periodic-kubernetes-unit-test-ppc64le TestCleanup Probably since it was merged in https://k8s- No response The error from build log trace is: Please go through the above job for complete build log. /sig testing
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
This test has been constantly failing in our environment and not just flaking. Also, We see it still failing even after your fix for is the job that ran after merge of
^^
cc
This is a data race in the control plane setup. cc
So yes, this is different from the failure that I ran into. It's still a flake (races don''t always go wrong), but apparently the conditions in your jobs are so that it always triggers.
I'll take care of this /assign
At first glance it looks like access to in lacks protection by a mutex. But why are and racing with each other in different goroutines, and why is called first?
in some executions it seems that it just timeouts, no races I think that the problem is that this environment is under resourced and this test is not able to boot the apsierver , that may explain the race and why Stop is racing with Start
Should we perhaps make this unit test run only on amd64 architectures, with the rationale a) that it isn't architecture-dependent and thus testing it in one unit test job is sufficient and b) that it is an expensive test that stresses slower architectures too much?
the apiserver times out starting up, I think we can make it lighter with it sound fair to me, since we use etcd and it is only guaranteed to build do you want to make the honors? or should I?
Can you do it because we probably want both and you know best how to explain the patch above in the commit message?

I thought about this twice, and I don't think we should tune the tests for running on constrained environments, this is a slippery slope, this environment is clearly constrained , there are also other issues reporting timeouts in this environment ... we should not tune test just to pass The skip based on etcd not supported may be reasonable though
Met this again when running , see
this is for the ppc64le specific problem, we should open a new one for this test it seems there were 2 occurrences more
For tracking, opened a new issue here
Change:
// plugin to use standard input. This is kept here in order to keep all of the exec configuration // together, but it is never serialized. // +k8s:conversion-gen=false <del> StdinUnavailable bool </del> <ins> StdinUnavailable bool `json:"-"` </ins> // StdinUnavailableMessage is an optional message to be displayed when the exec authenticator // cannot successfully run this exec plugin because it needs to use standard input and // StdinUnavailable is true. For example, a process that is already using standard input to // read user instructions might set this to "used by my-program to read user instructions". // +k8s:conversion-gen=false <del> StdinUnavailableMessage string </del> <ins> StdinUnavailableMessage string `json:"-"` </ins> } var _ fmt.Stringer = new(ExecConfig)

Discussion:
yaml.Marshal a kubeconfig, as done in the example tests here LocationOfOrigin is not seen in output, as comment says "never serialized." Click "run example" doesn't suffer from this as it does some conversion <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
/assign /triage accepted
is what's known as internal type. It is not intended to be serialized by code. The serialization version is in and does not have this field. I could get behind removing all json tags from the internal version, but I wouldn't refine tags that shouldn't be used.
Change:
func (s *store) Delete(ctx context.Context, key string, out runtime.Object, preconditions *storage.Preconditions, validateDeletion storage.ValidateObjectFunc) error { v, err := conversion.EnforcePtr(out) if err != nil { <del> panic("unable to convert output object to pointer") </del> <ins> return fmt.Errorf("unable to convert output object to pointer: %v", err) </ins> } key = path.Join(s.pathPrefix, key) return s.conditionalDelete(ctx, key, out, v, preconditions, validateDeletion)

Discussion:
Remove panic in , please return error instead following .
/sig api-machinery /good-first-issue
This request has been marked as suitable for new contributors. 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 : /sig api-machinery /good-first-issue 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
/assign
Please also add some log if returns error
/remove-kind bug /kind cleanup
Change:
function start_kubedns { if [[ "${ENABLE_CLUSTER_DNS}" = true ]]; then cp "${KUBE_ROOT}/cluster/addons/dns/kube-dns/kube-dns.yaml.in" kube-dns.yaml <del> sed -i -e "s/{{ pillar['dns_domain'] }}/${DNS_DOMAIN}/g" kube-dns.yaml sed -i -e "s/{{ pillar['dns_server'] }}/${DNS_SERVER_IP}/g" kube-dns.yaml </del> <ins> ${SED} -i -e "s/{{ pillar['dns_domain'] }}/${DNS_DOMAIN}/g" kube-dns.yaml ${SED} -i -e "s/{{ pillar['dns_server'] }}/${DNS_SERVER_IP}/g" kube-dns.yaml </ins> # TODO update to dns role once we have one. # use kubectl to create kubedns addon ${KUBECTL} --kubeconfig="${CERT_DIR}/admin.kubeconfig" --namespace=kube-system create -f kube-dns.yaml

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?: After running (on master branch), a new file named left as a surprise. and the file is not matched by git ignore so it's tracked by git which is really disturbing. I tried to find out where it's created but failed. Any one has a context w/ it? Environment: OS (e.g. from /etc/os-release): Darwin Kernel Version 17.6.0: Tue May 8 15:22:16 PDT 2018; root:xnu-4570.61.1~1/RELEASEX8664 x86_64
/sig instrumentation
the only piece of code in local-up-cluster that touches the file is
can't reproduce this. Two questions: Can you see this everytime? What is the SHA of the commit on master when you tried this? Can check with that too.
finally i realize that the cause is command is built receiving different flags between Linux and OSX. on Linux, you'll find that for linux sed the is explained as: '--in-place[=SUFFIX]' This option specifies that files are to be edited in-place. GNU 'sed' does this by creating a temporary file and sending output to this file rather than to the standard output.(1). so the is optional. but for OSX, it is: Edit files in-place, saving backups with the specified extension. If a zero-length extension is given, no backup will be saved. It is not recommended to give a zero- length extension when in-place editing files, as you risk corruption or partial content in situations where disk space is exhausted, etc. the difference is that on OSX, flag is requiring a variable , so when we're using on OSX in the script: the which is supposed to be received as a flag will be a suffix for the backup file. then the magic happened.will raise a fix for this. /assign
linking the difference between and
Change:
framework.ConformanceIt("should function for node-pod communication: udp [LinuxOnly] [NodeConformance]", func() { config := e2enetwork.NewCoreNetworkingTestConfig(f, true) for _, endpointPod := range config.EndpointPods { <del> config.DialFromNode("udp", endpointPod.Status.PodIP, e2enetwork.EndpointUDPPort, config.MaxTries, 0, sets.NewString(endpointPod.Name)) </del> <ins> err := config.DialFromNode("udp", endpointPod.Status.PodIP, e2enetwork.EndpointUDPPort, config.MaxTries, 0, sets.NewString(endpointPod.Name)) if err != nil { framework.Failf("Error dialing UDP from node to pod: %v", err) } </ins> } }) })

Discussion:
What happened: final passing output: What you expected to happen: Probably if this test passes, it should be showing several real endpoints. I don't know exactly what it does, but im assuming that the output could be clarified a little. How to reproduce it (as minimally and precisely as possible): run and look at the logs. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20 (sonobuoy)
/sig-network
/assign
/triage accepted
^ an interesting case here was that was but there was no SIG (typo in the command that did). should the label be only if there is label on the ticket? /sig network
the PR that adds triage/accepeted automation () was merged 3 hours ago, but it'll "actually" get rolled out in the next prow bump. Mostly when merges. Thanks for flagging though, appreciate it! :)
sorry, missed the actual question! :woman_facepalming: (need moar coffee!! :coffee: ) I don't think we should require a label for adding the label. In case someone comments with the following, we'd still want it to be valid.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
The above test cleans up the By directives and so on, After reading through the test more its clear that every test sets up a scaffold measures a property of that scaffold sometimes deletes something that is recovered in that scaffold (i.e. a pod that is behind a UDP service) So, the thing that was confusing I guess to me is that we validate empty conditions (i.e. no pods available) once we delete a nodePort svc. Meanwhile also noticed that the original work to clean up error reporting needed to cascade over to these tests as well.Have just finished all that, and also updated comments to reflect the Todo around the statistical computation (we have the ability to do extra polling via but we don't actually have any test that leverages this.As a follow on I guess it would be nice if we did have a test that confirmed that pods were load balanced evenly, esp with the new proliferation of different proxy technologies , I.e. a (or something similar
Change:
t.Fatalf("%d:, error writing to stderr: %v", i, err) } stderr.Close() <del> select { case <-clientStderrReadDone: case <-time.After(10 * time.Millisecond): t.Fatalf("%d: timed out waiting for client to read stderr", i) } </del> <ins> <-clientStderrReadDone </ins> } else if stderr != nil { t.Fatalf("%d: stderr: expected nil: %#v", i, stderr) }

Discussion:
this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.
Change:
"os/exec" "path" "path/filepath" <del> "runtime" </del> "strconv" "strings" "sync"

Discussion:
What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.
Change:
package oom import ( <ins> "os" </ins> "github.com/opencontainers/runc/libcontainer/cgroups" "testing"

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: What you expected to happen: The test should pass How to reproduce it (as minimally and precisely as possible): I think the key here is being on a linux host with cgroupsv2 enabled. 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: /sig node
/assign
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
Change:
// if >0 existing slices, mark all but 1 for deletion. slices.toDelete = existingSlices[1:] <del> // generated slices must mirror all endpoints annotations but EndpointsLastChangeTriggerTime compareAnnotations := cloneAndRemoveKeys(endpoints.Annotations, corev1.EndpointsLastChangeTriggerTime) </del> <ins> // generated slices must mirror all endpoints annotations but EndpointsLastChangeTriggerTime and LastAppliedConfigAnnotation compareAnnotations := cloneAndRemoveKeys(endpoints.Annotations, corev1.EndpointsLastChangeTriggerTime, corev1.LastAppliedConfigAnnotation) </ins> compareLabels := cloneAndRemoveKeys(existingSlices[0].Labels, discovery.LabelManagedBy, discovery.LabelServiceName) // Return early if first slice matches desired endpoints, labels and annotations totals = totalChanges(existingSlices[0], desiredSet)

Discussion:
If I modify a custom endpoint, the kubectl annotation is mirrored to the generated endpoint slice Since the kubect last-applied-configuration tracks the status of the object, it shouldn't be mirrored since it doesn't apply to the generated object a custom endpoint an update on any of the fields the generated endpoint slice annotations /sig network
ping
if we agree this is a bug, the fix is just and adding some tests of course :)
Thanks for catching this! Agree this is a bug that we should fix.
/triage accepted
/good-first-issue
This request has been marked as suitable for new contributors. 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 : /good-first-issue 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
Hey, I'm on it!
Hi While I have made the update mentioned in the above comment, I feel a bit lost on where to add/update tests. I understand that I probably shouldn't raise a PR without trying to add a few tests for this issue. So could you possibly guide me to the correct files(s) I should be looking into where the annotations for updated EndpointSlices are being tested?
Hey I think the easiest place to add tests might be here: You could add another test case where the Endpoints object had this label and then ensure that label was not copied over to an EndpointSlice.
Alright I'll check out these tests. Thank you!
/assign
Change:
package e2enode import ( <ins> "context" </ins> "fmt" "os" "os/exec" "os/user" <ins> "sync" </ins> "time" "k8s.io/klog" <ins> utilerrors "k8s.io/apimachinery/pkg/util/errors" </ins> "k8s.io/apimachinery/pkg/util/sets" internalapi "k8s.io/cri-api/pkg/apis" runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Unless disabled, the tests will prepull all images when running. They do so using the . I think there's the opportunity to improve the runtime of the test suite by prepulling the images in parallel. Why is this needed: Its always nicer to have faster tests :) Specifically for users running locally, it's nice to have the image prepull occur as quick as possible. That being said, we should also be cognizant of any tradeoffs associated with prepulling the images in parallel. If the code is substantially more complex, we would need a large improvement in test speed to justify it. I'm hopeful this discussion could be had once we have a proof of concept diff (which I think should be fairly minimal effort to create).
/sig node
I think this could be a good first issue for someone looking to get involved with contributing to sig-node :) Please post if you plan on working on it, so that there aren't multiple people tackling it.
I'd be interested! I'm looking for a first issue and think this would be a good one
Wonderful! Want to reach out to me on Kubernetes slack? I'm on there too :)
:wave: hiya ! Are you still thinking you could be interested in working on this? Lmk if so, and we can chat about next steps? If not, perhaps I'll open it back up to a newcomer looking for a first commit?
I'm going to open this back up for someone looking for a first commit. Lmk if you're still interest in getting sig-node, and happy to find an issue for you :)
Opening this back up for folks :) I'm happy to mentor whoever picks this up if that'd be helpful :) Ping me on k8s-slack, where I'm also
Can you assign this to meI'd be interested!
/assign
Awesome - feel free to reach out on k8s-slack if you have questions, or if you already have a plan, feel free to tag me in the pull request. Thanks :)
/lifecycle active /priority important-longterm
Change:
StabilityLevel: metrics.ALPHA, }, ) <del> SchedulingAlgorithmPreemptionEvaluationDuration = metrics.NewHistogram( </del> <ins> DeprecatedSchedulingAlgorithmPreemptionEvaluationDuration = metrics.NewHistogram( </ins> &metrics.HistogramOpts{ <del> Subsystem:      SchedulerSubsystem, Name:           "scheduling_algorithm_preemption_evaluation_seconds", Help:           "Scheduling algorithm preemption evaluation duration in seconds", Buckets:        metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel: metrics.ALPHA, </del> <ins> Subsystem:         SchedulerSubsystem, Name:              "scheduling_algorithm_preemption_evaluation_seconds", Help:              "Scheduling algorithm preemption evaluation duration in seconds", Buckets:           metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel:    metrics.ALPHA, DeprecatedVersion: "1.20.0", </ins> }, ) <del> BindingLatency = metrics.NewHistogram( </del> <ins> DeprecatedBindingLatency = metrics.NewHistogram( </ins> &metrics.HistogramOpts{ <del> Subsystem:      SchedulerSubsystem, Name:           "binding_duration_seconds", Help:           "Binding latency in seconds", Buckets:        metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel: metrics.ALPHA, </del> <ins> Subsystem:         SchedulerSubsystem, Name:              "binding_duration_seconds", Help:              "Binding latency in seconds", Buckets:           metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel:    metrics.ALPHA, DeprecatedVersion: "1.20.0", </ins> }, ) PreemptionVictims = metrics.NewHistogram(

Discussion:
Mark the following metrics as deprecated and . Both of those metrics are now covered as part of , the former as a the latter and a plugin. This can be done by setting in each of the two metrics opts. Changing the name of the metric variable to be prefixed with "Deprecated" is useful as well. /help /sig scheduling
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 : Mark the following metrics as deprecated and . Both of those metrics are now covered as part of , the former as a the latter and a plugin. /sig scheduling 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
/assign
/kind deprecation
Change:
if kubelettypes.IsCriticalPod(attrs.Pod) { return lifecycle.PodAdmitResult{Admit: true} } <del> // the node has memory pressure, admit if not best-effort if hasNodeCondition(m.nodeConditions, v1.NodeMemoryPressure) { </del> <ins> // Conditions other than memory pressure reject all pods nodeOnlyHasMemoryPressureCondition := hasNodeCondition(m.nodeConditions, v1.NodeMemoryPressure) && len(m.nodeConditions) == 1 if nodeOnlyHasMemoryPressureCondition { </ins> notBestEffort := v1.PodQOSBestEffort != v1qos.GetPodQOS(attrs.Pod) if notBestEffort { return lifecycle.PodAdmitResult{Admit: true}

Discussion:
<!-- STOP -- PLEASE READ! GitHub is not the right place for support requests. If you're looking for help, check and the . You can also post your question on the or the forum. If the matter is security related, please disclose it privately via --In the code below, kubelet rejects pods with QOS type guaranteed when under disk pressure, but when kubelet is also under memory pressure, those pods are accepted, is this behavior expected? Why is that?
/area kubelet /sig node
See this comment: It came with commit
you can find an answer from the proposal doc:
thank you ! I think current code is not following the eviction design of condition. the proposal is: but the code is: , guaranteed pods are not rejected any more. seems to be working fine though, maybe here's the reason: PS: above content can be found in
Change:
done # Let the minion know who its master is <ins> # Recover the salt-minion if the salt-master network changes ## auth_timeout - how long we want to wait for a time out ## auth_tries - how many times we will retry before restarting salt-minion ## auth_safemode - if our cert is rejected, we will restart salt minion ## ping_interval - restart the minion if we cannot ping the master after 1 minute ## random_reauth_delay - wait 0-3 seconds when reauthenticating ## recon_default - how long to wait before reconnecting ## recon_max - how long you will wait upper bound ## state_aggregrate - try to do a single yum command to install all referenced packages where possible at once, should improve startup times ## </ins> mkdir -p /etc/salt/minion.d cat <<EOF >/etc/salt/minion.d/master.conf master: '$(echo "$MASTER_NAME" | sed -e "s/'/''/g")' <ins> auth_timeout: 10 auth_tries: 2 auth_safemode: True ping_interval: 1 random_reauth_delay: 3 state_aggregrate: - pkg </ins> EOF cat <<EOF >/etc/salt/minion.d/log-level-debug.conf

Discussion:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?