jiebi/CodeConvo huggingface dataset:
Code change:
ErrCodeResourceVersionConflicts: "resource version conflicts", ErrCodeInvalidObj:               "invalid object", ErrCodeUnreachable:              "server unreachable", <ins> ErrCodeTimeout:                  "request timeout", </ins> } func NewKeyNotFoundError(key string, rv int64) *StorageError {

Related discussion:
text: We need more granular latency tracker especially on the latency spent on decoding. Right now, it only captures etcd round trip and transformer latency.
I would be supportive for both and would be happy to review it if someone opens up a PR for it.
/triage accepted
/assign
/reopen I think we need to reopen it to document how we resolved the unit test failures brought on by adding it
Reopened this issue. <detailsIn response to : /reopen I think we need to reopen it to document how we resolved the unit test failures brought on by adding it 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
Code change:
reportDir = flag.String("report-dir", "", "Path to the directory where the JUnit XML reports should be saved. Default is empty, which doesn't generate these reports.") ) <del> type failReporter struct { failed bool } func (f *failReporter) SpecSuiteWillBegin(config config.GinkgoConfigType, summary *types.SuiteSummary) { } func (f *failReporter) BeforeSuiteDidRun(setupSummary *types.SetupSummary) {} func (f *failReporter) SpecWillRun(specSummary *types.SpecSummary)         {} func (f *failReporter) SpecDidComplete(specSummary *types.SpecSummary) { if specSummary.Failed() { f.failed = true } } func (f *failReporter) AfterSuiteDidRun(setupSummary *types.SetupSummary) {} func (f *failReporter) SpecSuiteDidEnd(summary *types.SuiteSummary)       {} </del> func init() { // Turn on verbose by default to get spec names config.DefaultReporterConfig.Verbose = true

Related discussion:
text: We for uploading to GCS on , but not on successful e2e runs or failed test -up. We should definitely be dumping those logs for failed cluster-ups, and it would also be nice to throw in the successes too (good to have recent green for comparison).
Getting logs uploaded on a failed test -up seems really important for debugging.
+1 There were just a bunch of failures in scalability test suite (run 1623-1628) that failed because not all system pods were running. Since there are no logs, there is no easy way to debug it. It would be super useful to have all the logs for failed cluster-ups. cc
Unless I'm confused, it looks as if these logs are still not being uploaded. FYI.
For example: gs://kubernetes-jenkins/logs/kubernetes-e2e-gce/7500
That particular build was a timeout. When Jenkins kills the job, the log-collecting code never runs.
Another case we won't collect logs is if the cluster fails to initialize. (Which is a really important place to collect logs, but it's not a trivial fix.)
Moving this into post, since it seems unlikely to get fixed in the near term. feel free to correct me if I'm wrong.
We also don't collect logs on test job timeouts, which is frustrating.
+1
will collect the logs when the cluster fails to initialize. That's not all the cases listed here, but it's a good one.
I'd like to bump the priority for this further - we don't have any logs to help with debugging , which started to happen more often recently - it seems that didn't help. cc
I have too many P0s assigned to me already. This is at least 3rd in line right now.
This one is half year old and is P0 for a month...
From discussion with on hangouts, a vague plan: move log-dumping logic from into a standalone command in something like (feel free to bikeshed the name) update Jenkins to call this command as a post-build step probably remove and the debug stuff recently to . Right now the stuff is pretty GCE/GKE specific and uses ssh. We should probably change to a more provider-agnostic method, but this would be a good start.
Hm, actually, post-build step actually won't work, since we tear down the cluster first.
Code change:
reportDir = flag.String("report-dir", "", "Path to the directory where the JUnit XML reports should be saved. Default is empty, which doesn't generate these reports.") ) <del> type failReporter struct { failed bool } func (f *failReporter) SpecSuiteWillBegin(config config.GinkgoConfigType, summary *types.SuiteSummary) { } func (f *failReporter) BeforeSuiteDidRun(setupSummary *types.SetupSummary) {} func (f *failReporter) SpecWillRun(specSummary *types.SpecSummary)         {} func (f *failReporter) SpecDidComplete(specSummary *types.SpecSummary) { if specSummary.Failed() { f.failed = true } } func (f *failReporter) AfterSuiteDidRun(setupSummary *types.SetupSummary) {} func (f *failReporter) SpecSuiteDidEnd(summary *types.SuiteSummary)       {} </del> func init() { // Turn on verbose by default to get spec names config.DefaultReporterConfig.Verbose = true

Related discussion:
text: But making it a separate command can still let us call it in more places.
FYI - we also need logs from timed-out runs (not only the failed ones).
moving out into its own binary should help accomplish this.
I'm worried that the best way to do this is to write a bash script that grabs IPs from 's and functions and just does an ssh and cats the logs. Then we could point at that. It's sorta difficult to make work on its own.
I think at this point we're happy with anything that usually works. We can work on making in nice and shiny later.
We now get logs when kube-up fails, which recently happened :) Still some work to do here, I'll leave this issue open until timeouts are handled properly and points here.
- I can't thank you enough!
Ok, is in so we should get logs for kubernetes-e2e-* jobs and PR Jenkins jobs on timeout.
I'm gonna call this done.
Code change:
# Translate a published version <bucket>/<version> (e.g. "release/stable") to version number. set_binary_version "${release}" if [[ -z "${KUBERNETES_SKIP_RELEASE_VALIDATION-}" ]]; then <del> if [[ ${KUBE_VERSION} =~ ${KUBE_CI_VERSION_REGEX} ]]; then </del> <ins> if [[ ${KUBE_VERSION} =~ ${KUBE_RELEASE_VERSION_REGEX} ]]; then # Use KUBERNETES_RELEASE_URL for Releases and Pre-Releases # ie. 1.18.0 or 1.19.0-beta.0 KUBERNETES_RELEASE_URL="${KUBERNETES_RELEASE_URL}" elif [[ ${KUBE_VERSION} =~ ${KUBE_CI_VERSION_REGEX} ]]; then </ins> # Override KUBERNETES_RELEASE_URL to point to the CI bucket; # this will be used by get-kube-binaries.sh. <ins> # ie. v1.19.0-beta.0.318+b618411f1edb98 </ins> KUBERNETES_RELEASE_URL="${KUBERNETES_CI_RELEASE_URL}" <del> elif ! [[ ${KUBE_VERSION} =~ ${KUBE_RELEASE_VERSION_REGEX} ]]; then </del> <ins> else </ins> echo "Version doesn't match regexp" >&2 exit 1 fi

Related discussion:
text: If you give a prerelease version to , it'll match both and . Based on this logic: We'll end up trying to pull binaries for this prerelease from the CI bucket () rather than the release bucket (). These pre-release versions are usually* pushed to the release bucket as part of the release process (e.g. ), and so should probably prefer these over the CI versions (which may or may not exist, depending on whether a commit was pushed to the release branch between when the tag was created and the build occurred). More explicitly, the current logic is: the release bucket by default. a version matches the CI regex, use the CI bucket. , if a version matches the release regex, we're good - continue to use the default (release bucket). , bail out - invalid version. The correct logic would probably be something like the release bucket by default. a version matches the release version regex, continue to use the release bucket. , if a version doesn't match the release version regex, but it matches the CI regex, use the CI bucket. it matches neither, bail out. Important note: due to our hotfix for , there is a somewhat fake prerelease tag () which doesn't have any bits in the release bucket, and we expect others soon. We should not fix this bug in until the latest pointers in the CI bucket do not point to valid release/prerelease versions.
/sig testing /sig release I guess?
/area release-eng /priority critical-urgent /assign /milestone v1.18
Hello With code freeze approaching for 1.18 (5 March), can you please check if the current issue is still intended for milestone 1.18?
-- I'm pretty sure I can get to this before the cycle is out.
if our current approach for tagging release branch pre-releases doesn't trigger this, this seems like it is not critical for the milestone, is that correct?
-- Good point! /milestone v1.19 /remove-priority critical-urgent /priority important-soon
Given the priority dip on this one, I think it's fine for someone in Releng other than Tim or I to pick this up. /unassign -- This is a good one to work on. /help
I can look that, after the release 1.18, if is that fine then can we have a short discussion about this one? /remove-help /assign
-- SGTM
Code change:
root="$(cd "${root}" && pwd -P)" local input_pkgs=( "${extra_pkgs[@]:+"${extra_pkgs[@]}"}") <del> while read -r file; do dir="$(dirname "${file}")" </del> <ins> while read -r dir; do </ins> pkg="$(cd "${dir}" && GO111MODULE=on go list -find .)" input_pkgs+=("${pkg}") done < <( <del> ( kube::codegen::internal::git_grep -l  </del> <ins> ( kube::codegen::internal::git_grep -l --null  </ins> -e '+k8s:openapi-gen='  ":(glob)${root}"/'**/*.go'  || true  <del> ) | LC_ALL=C sort -u </del> <ins> ) | xargs -0 -n1 dirname  | LC_ALL=C sort -u </ins> ) if [ "${#input_pkgs[@]}" != 0 ]; then

Related discussion:
text: function in script has following issues: function only supports file but we have multiple types file with name as in . Hence this function is not working in our case. For the mitigation there is already an open . I have asked for including our changes as well. We have multiple files under a for example and . Because of this for appears twice and it generates duplicate informers We only need unique elements before passing it to . I followed this approach for unique elements: We have packages under . Earlier we were generating client only for and . But with the new I am not able to do that. I am using the following call to function: It results in following flags to As there is no directory as , it doesnot generate anything. Is it still possible to call on specific folder as it was done with earlier scripts? One mitigation I can think of is to call function on whole and then remove the marker from the types for which genclient is not needed. But the issue is we won't be able to pass the flag for each pkg. function in script is not working as expected.
/sig api-machinery
/cc
/triage accepted
Hi . I knew that there were all sorts of clients out there doing all sorts of things with these scripts, so I am not surprised to find you. :) Do you have a PR which attempts to use kube_codegen, so I can repro your issues directly?
I think you have one too many in there Aside from that, the real problem here is that these old codegen tools make some deeeeeeep assumptions about the ability to string-join various arguments and get the right results. It's awful. I was trying to make it simpler in this script, which I did for all of the in-tree consumers, but out of tree people apparently don't always follow the same conventions. For example, we generate clients for every directory that requests it. For a reason I do not know, you have files like which say but you don't actually want a client? If you specify then it t
So this code expects that you generate an omnibus client. What if I add a flag, like which you can use to call it for each API to make distinct clients? In truth the codegen tools need to be fixed, but that has SO MUCH ripple I just can't right now.
Code change:
root="$(cd "${root}" && pwd -P)" local input_pkgs=( "${extra_pkgs[@]:+"${extra_pkgs[@]}"}") <del> while read -r file; do dir="$(dirname "${file}")" </del> <ins> while read -r dir; do </ins> pkg="$(cd "${dir}" && GO111MODULE=on go list -find .)" input_pkgs+=("${pkg}") done < <( <del> ( kube::codegen::internal::git_grep -l  </del> <ins> ( kube::codegen::internal::git_grep -l --null  </ins> -e '+k8s:openapi-gen='  ":(glob)${root}"/'**/*.go'  || true  <del> ) | LC_ALL=C sort -u </del> <ins> ) | xargs -0 -n1 dirname  | LC_ALL=C sort -u </ins> ) if [ "${#input_pkgs[@]}" != 0 ]; then

Related discussion:
text: As the codegen was breaking us at several step, hence didn't prepared the PR.
Thanks for the PR. I have one more concern, is it possible to call and client-gen on the same pkg? With the current script, that is not possible because of the line It removes all the generated files first and then calls the . Hence the later clientset gen will remove the earlier generated clients.
Why are you generating a client for an internal version that isn't served?
My mistake. We need to stop using clients for internal versions.
Code change:
if !allowedTransitions[pair{from, to}] { t.Errorf("observed transition %q -> %q for %v", from, to, n.Name) } <del> source.Delete(n) </del> <ins> if deletePod(n) { source.Delete(n) } </ins> }, DeleteFunc: func(obj interface{}) { testDoneWG.Done()

Related discussion:
text: I got this by running the following against commit : There have been previous attempts to fix this: It appears it's still an issue :cry: We're also seeing it in OpenShift (), although our code hasn't pulled in the fix from quite yet.
cc
What go version are you using? Previously this test has been catching legit bugs, so I'm not sure about the "flaky" moniker.
go 1.5.1. I noticed you had a comment in another issue or PR about this possibly being a bug in Go itself (or did I misread)?
I doubt it's a bug in go. (go1.5 had an unrelated bug, maybe that's what you're thinking of.) We haven't actually flipped 1.5 on so I may sit on this for a bit.
I instrumented this code, and this is being caused by duplicate deletions causing the wait group to decrement below 0. Are duplicate deletions a bug? Or should the wait group be guarded against that?
ping If duplicate deletes are not a bug, I can put together a quick PR to guard against that. If they are a bug, I could try to track it down sometime this week (even thought I'm not that familiar with this code) if no one else is going to look into it.
Duplicate deletes are a bug. (assuming that the test harness isn't actually issuing multiple deletes for the same item.)
That would be great if you could take this, since I won't have time.
So it would be an error in the test if was called multiple times for the same pod? Or should the framework be de-duping that?
IMO, that's a test error. ...If the test is doing that because the framework dup'd an update or an add, then it's a framework error. (adds and updates shouldn't be duped, either) , krousey wrote:
from what I gather, this test is just trying to delete after each pod reaches it's final intended state. This code is deleting on every event, including intermediate ones. In particular, this test case is occasionally causing duplicate deletes to be issued: Sometimes it catches the transition from FROM to ADDMISSED, and then gets ADDMISSED to TO. I think the fix is to tell the test to only issue the delete when the final state is TO.
Code change:
if !allowedTransitions[pair{from, to}] { t.Errorf("observed transition %q -> %q for %v", from, to, n.Name) } <del> source.Delete(n) </del> <ins> if deletePod(n) { source.Delete(n) } </ins> }, DeleteFunc: func(obj interface{}) { testDoneWG.Done()

Related discussion:
text: I'll do that and some stress testing to see if it goes away.
3589 runs so far, 10 failures and all 10 failures seem to confirm the above behavior.
Guarding against this: runs so far, 0 failures I will clean this up and send out a fix shortly.
Awesome, thanks! , krousey wrote:
Accidentally left the test case running. Good news:
It's probably safe to say that if there's remaining corner cases, your setup is not going to exercise them! :) , krousey wrote:
Code change:
allErrs = append(allErrs, validateProbe(ctr.ReadinessProbe, idxPath.Child("readinessProbe"))...) allErrs = append(allErrs, validateContainerPorts(ctr.Ports, idxPath.Child("ports"))...) allErrs = append(allErrs, ValidateEnv(ctr.Env, idxPath.Child("env"))...) <ins> allErrs = append(allErrs, ValidateEnvFrom(ctr.EnvFrom, idxPath.Child("envFrom"))...) </ins> allErrs = append(allErrs, ValidateVolumeMounts(ctr.VolumeMounts, volumes, idxPath.Child("volumeMounts"))...) allErrs = append(allErrs, validatePullPolicy(ctr.ImagePullPolicy, idxPath.Child("imagePullPolicy"))...) allErrs = append(allErrs, ValidateResourceRequirements(&ctr.Resources, idxPath.Child("resources"))...)

Related discussion:
text: Scenario: Expected results: pod would not be created as [0] is invalid Actual results: pod is created. Turns out we are not doing any validation of envFrom in container spec today.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
I don't know that we can tighten without failing pods.
The validation code exists, but there was no wiring done from validateContainers.
Pods fail on kubelet already. So those pods were not doing much already. We had a BZ on this.
Fail how - fail to even start, or fail to get the input?
Code change:
klog.Warningf("Bad device-number %q for interface %sn", numStr, macID) continue } <ins> macIDs = append(macIDs, macID) macDevNum[macID] = num } // Sort macIDs by interface device-number sort.Slice(macIDs, func(i, j int) bool { return macDevNum[macIDs[i]] < macDevNum[macIDs[j]] }) for _, macID := range macIDs { </ins> ipPath := path.Join("network/interfaces/macs/", macID, "local-ipv4s") <del> macIPs[num], err = c.metadata.GetMetadata(ipPath) </del> <ins> internalIPs, err := c.metadata.GetMetadata(ipPath) </ins> if err != nil { return nil, fmt.Errorf("error querying AWS metadata for %q: %q", ipPath, err) } <del> } for i := 0; i < len(macIPs); i++ { internalIPs := macIPs[i] if internalIPs == "" { continue } </del> for _, internalIP := range strings.Split(internalIPs, "n") { if internalIP == "" { continue

Related discussion:
text: What happened: does not handle "holes" in interface device-number correctly, dropping later interfaces. Create instance with eth0, eth1, eth2 ENIs as usual. Remove (eg: by selectively deleting pods) eth1. Only the addresses on eth0 are reported by NodeAddresses. What you expected to happen: Addresses on eth0 and eth2 should be reported.
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
Code change:
<ins> /* Copyright 2020 The Kubernetes Authors. 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. */ package apimachinery import ( "k8s.io/apimachinery/pkg/version" "k8s.io/kubernetes/test/e2e/framework" "regexp" "github.com/onsi/ginkgo" ) var _ = SIGDescribe("server version", func() { f := framework.NewDefaultFramework("server-version") ginkgo.It("should find the server version", func() { ginkgo.By("Request ServerVersion") var version *version.Info version, err := f.ClientSet.Discovery().ServerVersion() framework.ExpectNoError(err, "Fail to access ServerVersion") ginkgo.By("Confirm major version") re := regexp.MustCompile("[1-9]") framework.ExpectEqual(re.FindString(version.Major), version.Major, "unable to find major version") framework.Logf("Major version: %v", version.Major) ginkgo.By("Confirm minor version") re = regexp.MustCompile("[^0-9]+") cleanMinorVersion := re.ReplaceAllString(version.Minor, "") framework.Logf("cleanMinorVersion: %v", cleanMinorVersion) re = regexp.MustCompile("[0-9]+") framework.ExpectEqual(re.FindString(version.Minor), cleanMinorVersion, "unable to find minor version") framework.Logf("Minor version: %v", version.Minor) }) }) </ins>

Related discussion:
text: 3 July 2020 [x] Two weeks soak end date: 20 July 2020 According to this APIsnoop query, there are still an endpoint which is untested. Get the server version (hits api path /version) Check that the major version is current Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
/reopen was Merge but the merge was reversed by Issue and Test grid restarted.
Reopened this issue. <detailsIn response to : /reopen was Merge but the merge was reversed by Issue and Test grid restarted. </details
Automatic retest and Merge again
Code change:
# REVISION provides a version number fo 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?=0 </del> <ins> REVISION?=1 </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)

Related discussion:
text: What would you like to be : Have debian-iptables with iptables 1.8.5+ Why is this needed: To fix (nodelocaldns + iptables-nft) More informations Found a bug in iptables-nft, fixed in iptables 1.8.5, and now available in buster-backports https://alioth-
/sig api-machinery
ping as you did the last 2 updates
Yep, this is on my list. Will take of it next week. /sig release network /area release-eng /milestone v1.20 /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Opened to bump the debian-iptables images in kubernetes/kubernetes. /remove-triage unresolved
Here are the digests for the new image ():
Please reopen if you run into any issues with the new images. /close
Closing this issue. <detailsIn response to : Please reopen if you run into any issues with the new images. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Code change:
if err != nil { t.Fatalf("Failed to install plugin %s: %v", confFile, err) } <del> networkConfig := fmt.Sprintf(`{ "name": "%s", "type": "%s", "capabilities": {"portMappings": true, "bandwidth": true}  }`, confName, binName) </del> <ins> networkConfig := fmt.Sprintf(`{ "name": "%s", "type": "%s", "capabilities": {"portMappings": true, "bandwidth": true, "ipRanges": true}  }`, confName, binName) </ins> _, err = f.WriteString(networkConfig) if err != nil { t.Fatalf("Failed to write network config file (%v)", err)

Related discussion:
text: /kind feature The CNI "capability arguments" parameter - currently used to pass port mappings - has a few new capabilities: bandwidth limiting and network address management. The dockershim's networking driver should use them. The network address is just passing the PodCIDR dynamically to the plugin, so it no longer has to retrieve it from the APIServer. Bandwidth limiting is already implemented in Kubenet. It is configured via annotations. There is no upgrade risk in providing these values; non-compliant plugins will simply ignore them. Administrators need to explicitly enable each capability individually in their CNI configuration file. To avoid skew between runtimes, the other runtimes should also be upgraded to pass these. We may also wish to look in to a way to add this more directly to the CRI, so we don't have this skew problem, but that's a different issue.
/sig network
/assign
fyi.
Looks like this was never done for CRI?
cc