jiebi/CodeConvo huggingface dataset:
Code change:
we have one in k/k and one in k/utils, both need to be in LICENSES /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
/area code-organization
I think we should include anything matching the LICENSE/COPYRIGHT/COPYING patthers under or subdirs in k/k or dependencies... a quick sweep showed these:
/sig release ?

Related discussion:
text: <ins> Copyright 2011-2016 Canonical Ltd. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. </ins>
Code change:
we have one in k/k and one in k/utils, both need to be in LICENSES /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
/area code-organization
I think we should include anything matching the LICENSE/COPYRIGHT/COPYING patthers under or subdirs in k/k or dependencies... a quick sweep showed these:
/sig release ?

Related discussion:
text: <ins> The MIT License (MIT) Copyright (c) 2018 QRI, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. </ins>
Code change:
we have one in k/k and one in k/utils, both need to be in LICENSES /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
/area code-organization
I think we should include anything matching the LICENSE/COPYRIGHT/COPYING patthers under or subdirs in k/k or dependencies... a quick sweep showed these:
/sig release ?

Related discussion:
text: mv "${TMP_LICENSE_FILE}" "${dest_dir}/LICENSE" done <ins> # copy licenses for forked code from vendor and third_party directories (cd "${KUBE_ROOT}" &&  find vendor third_party -iname 'licen[sc]e*' -o -iname 'notice*' -o -iname 'copying*' |  grep -E 'third_party|forked' |  xargs tar -czf - | tar -C "${TMP_LICENSES_DIR}" -xzf -) </ins> # Leave things like OWNERS alone. rm -f "${LICENSES_DIR}/LICENSE" rm -rf "${LICENSES_DIR}/vendor" <ins> rm -rf "${LICENSES_DIR}/third_party" </ins> mv "${TMP_LICENSES_DIR}"/* "${LICENSES_DIR}"
Code change:
<!-- 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 -- [sig-node] Pods should delete a collection of pods [Conformance] TBD links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
cc /sig windows
I've looked through the logs for a bit and the test itself. What the test is doing: create 3 pods. expect to find 3 pods (it doesn't seem to wait for the to start, they only need to exist). delete all 3 of them as a collection. expect all 3 pods to dissapear. All 3 pods ended up on the same node, plus some other tests were running in parallel, which could also contribute to the failure. Looking at the kubelet logs, it seems that was the remaining pod to be deleted. Filtering the logs, we can see: The test failed at, while the other 2 pods did: Those times correspond with the number of pods observed by the test: Now, my question is, why are there such big gaps between the ` events? It's 12s for test-pod-2 and 21s for test-pod-3? Seems like a long time for pods / containers to linger after they've been killed. PS: It seems that Containers are still being created / started / stopped, even if the delete request came less than 0.2s after their creation. It doesn't seem to me like a reasonable thing to do, especially if that Pod would have to pull a huge image; I would have expected to be able to cancel that.
/triage accepted
Let's discuss at the 8/17 SIG-Windows community meeting
Hit again on 8/15
I think was planning on opening up a PR to use longer timeouts in this test. We see that some Windows containers do not get scheduled until 1+ minutes into the test - especially when there are many tests running in parallel.

Related discussion:
text: }}, metav1.CreateOptions{}) framework.ExpectNoError(err, "failed to create pod") framework.Logf("created %v", podTestName) <ins> framework.ExpectNoError(e2epod.WaitForPodNameRunningInNamespace(f.ClientSet, podTestName, f.Namespace.Name)) framework.Logf("running and ready %v", podTestName) </ins> } // wait as required for all 3 pods to be found
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- - At least 08/08 sequentially performs operations that take ~20s on average. Example: For a 5000 nodes test this causes a major timeout. excludes tests with tag which SCTP had until was merged. This is why there is a shift in red cells in the testgrid after 08/15. We will add a pattern excluding until this issue is resolved. /assign /cc
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 network
/assign

Related discussion:
text: jig := e2eservice.NewTestJig(cs, ns, serviceName) ginkgo.By("getting the state of the sctp module on nodes") <del> nodes, err := e2enode.GetReadySchedulableNodes(cs) </del> <ins> nodes, err := e2enode.GetBoundedReadySchedulableNodes(cs, 2) </ins> framework.ExpectNoError(err) sctpLoadedAtStart := CheckSCTPModuleLoadedOnNodes(f, nodes)
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- - At least 08/08 sequentially performs operations that take ~20s on average. Example: For a 5000 nodes test this causes a major timeout. excludes tests with tag which SCTP had until was merged. This is why there is a shift in red cells in the testgrid after 08/15. We will add a pattern excluding until this issue is resolved. /assign /cc
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 network
/assign

Related discussion:
text: framework.ExpectNoError(err, fmt.Sprintf("error while waiting for service:%s err: %v", serviceName, err)) hostExec := utils.NewHostExec(f) defer hostExec.Cleanup() <del> node, err := e2enode.GetRandomReadySchedulableNode(cs) framework.ExpectNoError(err) </del> <ins> node := &nodes.Items[0] </ins> cmd := "iptables-save" if framework.TestContext.ClusterIsIPv6() { cmd = "ip6tables-save"
Code change:
TestRecordOperation TestRecordOperation TestGetHistogramVecFromGatherer /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --/sig testing This may be related with 
/assign I will do some initial researches on this. is similar
/sig instrument
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrument Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig instrumentation
/triage accepted /assign cc
To fix it gracefully, we may refactor the code in like The refactor would change a lot and need some confirmations or demo.(I prefer) A temporary workaround before refactoring it: is another try to ignore the dup error in but it is odd as should panic as designed if one register failed.
Three testings failed due to . Haven't found package promauto () being used in these testings. It might be other issues. These testings are: /filterwithonelabel
What are you guys doing here? What test is this? You cannot change the component-base metrics code base it is doing what it is supposed to be doing. Does this test suite involve multiple sequential runs of the same test?
I think this is odd to change the component-base metrics code base. But the refactor to use is another approach. You can try to reproduce it with is with
Oh, yes. This involves multiple sequential runs of the same test to . It uses 
You can use to register the registry only once. It is important to reset the metrics, or next iteration in the test will fail
Thanks I other fixes in

Related discussion:
text: "github.com/stretchr/testify/assert" <del> "k8s.io/component-base/metrics/legacyregistry" </del> <ins> compbasemetrics "k8s.io/component-base/metrics" </ins> runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2" "k8s.io/kubernetes/pkg/kubelet/metrics" ) func TestRecordOperation(t *testing.T) { <del> legacyregistry.MustRegister(metrics.RuntimeOperations) legacyregistry.MustRegister(metrics.RuntimeOperationsDuration) legacyregistry.MustRegister(metrics.RuntimeOperationsErrors) </del> <ins> // Use local registry var registry = compbasemetrics.NewKubeRegistry() var gather compbasemetrics.Gatherer = registry registry.MustRegister(metrics.RuntimeOperations) registry.MustRegister(metrics.RuntimeOperationsDuration) registry.MustRegister(metrics.RuntimeOperationsErrors) registry.Reset() </ins> l, err := net.Listen("tcp", "127.0.0.1:0") assert.NoError(t, err)
Code change:
TestRecordOperation TestRecordOperation TestGetHistogramVecFromGatherer /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --/sig testing This may be related with 
/assign I will do some initial researches on this. is similar
/sig instrument
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrument Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig instrumentation
/triage accepted /assign cc
To fix it gracefully, we may refactor the code in like The refactor would change a lot and need some confirmations or demo.(I prefer) A temporary workaround before refactoring it: is another try to ignore the dup error in but it is odd as should panic as designed if one register failed.
Three testings failed due to . Haven't found package promauto () being used in these testings. It might be other issues. These testings are: /filterwithonelabel
What are you guys doing here? What test is this? You cannot change the component-base metrics code base it is doing what it is supposed to be doing. Does this test suite involve multiple sequential runs of the same test?
I think this is odd to change the component-base metrics code base. But the refactor to use is another approach. You can try to reproduce it with is with
Oh, yes. This involves multiple sequential runs of the same test to . It uses 
You can use to register the registry only once. It is important to reset the metrics, or next iteration in the test will fail
Thanks I other fixes in

Related discussion:
text: prometheusURL := "http://" + l.Addr().String() + "/metrics" mux := http.NewServeMux() <del> //lint:ignore SA1019 ignore deprecated warning until we move off of global registries mux.Handle("/metrics", legacyregistry.Handler()) </del> <ins> handler := compbasemetrics.HandlerFor(gather, compbasemetrics.HandlerOpts{}) mux.Handle("/metrics", handler) </ins> server := &http.Server{ Addr:    l.Addr().String(), Handler: mux,
Code change:
TestRecordOperation TestRecordOperation TestGetHistogramVecFromGatherer /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --/sig testing This may be related with 
/assign I will do some initial researches on this. is similar
/sig instrument
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrument Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig instrumentation
/triage accepted /assign cc
To fix it gracefully, we may refactor the code in like The refactor would change a lot and need some confirmations or demo.(I prefer) A temporary workaround before refactoring it: is another try to ignore the dup error in but it is odd as should panic as designed if one register failed.
Three testings failed due to . Haven't found package promauto () being used in these testings. It might be other issues. These testings are: /filterwithonelabel
What are you guys doing here? What test is this? You cannot change the component-base metrics code base it is doing what it is supposed to be doing. Does this test suite involve multiple sequential runs of the same test?
I think this is odd to change the component-base metrics code base. But the refactor to use is another approach. You can try to reproduce it with is with
Oh, yes. This involves multiple sequential runs of the same test to . It uses 
You can use to register the registry only once. It is important to reset the metrics, or next iteration in the test will fail
Thanks I other fixes in

Related discussion:
text: "fmt" "math" "reflect" <del> "sync" </del> "testing" "github.com/google/go-cmp/cmp" dto "github.com/prometheus/client_model/go" "k8s.io/component-base/metrics" <del> "k8s.io/component-base/metrics/legacyregistry" </del> "k8s.io/utils/pointer" )
Code change:
TestRecordOperation TestRecordOperation TestGetHistogramVecFromGatherer /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --/sig testing This may be related with 
/assign I will do some initial researches on this. is similar
/sig instrument
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrument Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig instrumentation
/triage accepted /assign cc
To fix it gracefully, we may refactor the code in like The refactor would change a lot and need some confirmations or demo.(I prefer) A temporary workaround before refactoring it: is another try to ignore the dup error in but it is odd as should panic as designed if one register failed.
Three testings failed due to . Haven't found package promauto () being used in these testings. It might be other issues. These testings are: /filterwithonelabel
What are you guys doing here? What test is this? You cannot change the component-base metrics code base it is doing what it is supposed to be doing. Does this test suite involve multiple sequential runs of the same test?
I think this is odd to change the component-base metrics code base. But the refactor to use is another approach. You can try to reproduce it with is with
Oh, yes. This involves multiple sequential runs of the same test to . It uses 
You can use to register the registry only once. It is important to reset the metrics, or next iteration in the test will fail
Thanks I other fixes in

Related discussion:
text: } func TestGetHistogramVecFromGatherer(t *testing.T) { <del> var registerMetrics sync.Once </del> tests := []struct { name    string lvMap   map[string]string
Code change:
TestRecordOperation TestRecordOperation TestGetHistogramVecFromGatherer /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --/sig testing This may be related with 
/assign I will do some initial researches on this. is similar
/sig instrument
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrument Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig instrumentation
/triage accepted /assign cc
To fix it gracefully, we may refactor the code in like The refactor would change a lot and need some confirmations or demo.(I prefer) A temporary workaround before refactoring it: is another try to ignore the dup error in but it is odd as should panic as designed if one register failed.
Three testings failed due to . Haven't found package promauto () being used in these testings. It might be other issues. These testings are: /filterwithonelabel
What are you guys doing here? What test is this? You cannot change the component-base metrics code base it is doing what it is supposed to be doing. Does this test suite involve multiple sequential runs of the same test?
I think this is odd to change the component-base metrics code base. But the refactor to use is another approach. You can try to reproduce it with is with
Oh, yes. This involves multiple sequential runs of the same test to . It uses 
You can use to register the registry only once. It is important to reset the metrics, or next iteration in the test will fail
Thanks I other fixes in

Related discussion:
text: Buckets:   buckets, } vec := metrics.NewHistogramVec(HistogramOpts, labels) <del> registerMetrics.Do(func() { legacyregistry.MustRegister(vec) }) </del> <ins> // Use local registry var registry = metrics.NewKubeRegistry() var gather metrics.Gatherer = registry registry.MustRegister(vec) </ins> // Observe two metrics with same value for label1 but different value of label2. vec.WithLabelValues("value1-0", "value2-0").Observe(1.5) vec.WithLabelValues("value1-0", "value2-1").Observe(2.5) vec.WithLabelValues("value1-1", "value2-0").Observe(3.5) vec.WithLabelValues("value1-1", "value2-1").Observe(4.5) metricName := fmt.Sprintf("%s_%s_%s", HistogramOpts.Namespace, HistogramOpts.Subsystem, HistogramOpts.Name) <del> histogramVec, _ := GetHistogramVecFromGatherer(legacyregistry.DefaultGatherer, metricName, tt.lvMap) </del> <ins> histogramVec, _ := GetHistogramVecFromGatherer(gather, metricName, tt.lvMap) </ins> if diff := cmp.Diff(tt.wantVec, histogramVec); diff != "" { t.Errorf("Got unexpected HistogramVec (-want +got):n%s", diff) }
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- post-kubernetes-push-image-etcd n/a 2020-08-11 Started failing when merged No new versions of etcd are getting pushed until this gets fixed, when means the following PRs haven't fully taken effect: /sig api-machinery /priority critical-urgent /milestone v1.23 /assign FYI
/sig release /area release-eng
I've opened to rollback the offending commit, would like to keep this open until we can figure out the correct fix-forward
/triage accepted
was triggered by the merge of , which pushed So that's now current / includes whatever PRs linked in the description may have tried to change (excluding )
does this need promotion at all or are we good with the existing image?
/remove-priority critical-urgent /priority important-soon The job is back to passing
Recent updates are related to Debian base image update and golang upgrade. Nice to get a promotion. Good enough to use .
Yeah, looks like that the env in the build job does not search for docker CLI plugins in the path, which makes it unavailable during the run.
I think we have to set the environment variable like we already do in other build jobs, proposing the fix in
Latest test run is green:

Related discussion:
text: # REVISION provides a version number for this image and all it's bundled # artifacts. It should start at zero for each LATEST_ETCD_VERSION and increment # for each revision of this image at that etcd version. <del> REVISION?=3 </del> <ins> REVISION?=4 </ins> # IMAGE_TAG Uniquely identifies k8s.gcr.io/etcd docker image with a tag of the form "<etcd-version>-<revision>". IMAGE_TAG=$(LATEST_ETCD_VERSION)-$(REVISION)
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- post-kubernetes-push-image-etcd n/a 2020-08-11 Started failing when merged No new versions of etcd are getting pushed until this gets fixed, when means the following PRs haven't fully taken effect: /sig api-machinery /priority critical-urgent /milestone v1.23 /assign FYI
/sig release /area release-eng
I've opened to rollback the offending commit, would like to keep this open until we can figure out the correct fix-forward
/triage accepted
was triggered by the merge of , which pushed So that's now current / includes whatever PRs linked in the description may have tried to change (excluding )
does this need promotion at all or are we good with the existing image?
/remove-priority critical-urgent /priority important-soon The job is back to passing
Recent updates are related to Debian base image update and golang upgrade. Nice to get a promotion. Good enough to use .
Yeah, looks like that the env in the build job does not search for docker CLI plugins in the path, which makes it unavailable during the run.
I think we have to set the environment variable like we already do in other build jobs, proposing the fix in
Latest test run is green:

Related discussion:
text: RUNNERIMAGE?=gcr.io/distroless/static:latest <ins> QEMUVERSION?=5.2.0-2 </ins> build: # Explicitly copy files to the temp directory $(BIN_INSTALL) migrate-if-needed.sh $(TEMP_DIR)