jiebi/CodeConvo huggingface dataset:
Change:
var _ Interface = new(Mock) <ins> func (c *Mock) Start() error { args := c.Called() return args.Error(1) } </ins> // ContainerInfo is a mock implementation of Interface.ContainerInfo. func (c *Mock) ContainerInfo(name string, req *cadvisorApi.ContainerInfoRequest) (*cadvisorApi.ContainerInfo, error) { args := c.Called(name, req)

Discussion:
This is blocking (reboot test). In running a test that reboots all of the nodes and then runs the e2e tests, we saw a failure with the influxdb / heapster monitoring test: The heapster logs, from running (), shows a ton of the following kubelet errors for all containers (this one happens to be for skydns): The shows a bunch of 500 errors, such as: However, the apiserver thinks that all the pods are running ( gives this ) Docker thinks that the pods are running ( on that node gives this ) In summary: apiserver and docker think containers are running but kubelet can't find them this manifested in the influxdb / heapster monitoring e2e test after node reboot I've still got the cluster around if anyone would like to debug. +cc (helped me debug this (thanks!)) +cc (node) +cc (interested in getting in, which this is blocking)
Can I access your test nodes?
Is this an active problem? I'd check if the cAdvisor thinks the containers exist (it is the one returning the error). I'd then scan the logs to see if cAdvisor had any errors related to that container.
Unfortunately during debugging, I restart kubelet service on that node, the issue is gone. The problem could be cadvisor cannot get stats, but I couldn't find any cadvisor related error messages. How easy to reproduce the issue here? Next time we might access cadvisor's page to see if there is no such container information. Thanks!
(and Thanks for looking into this! I believe I can reproduce easily but I'll confirm. Where do I look for cAdvisor info? I don't see a log in or , and I don't see a cAdvisor container running?
cAdvisor is running as part of kubelet now. If you can reproduce the issue, could you please change kubelet's log level to 4 so that we have more cadvisor log here? Thanks!
Yes! How do I do that?

I can reproduce this by doing the following: After this, I got two failures: ... and I have another node with more of the same kubelet errors: (If I need to change the Kubelet log level at compile-time I can do that and repro on a new cluster; otherwise, I've got another cluster with the issue that can be introspected...)
There is a race between cadvisor initialization and docker. cadvisor failed to register docker factory, and bailed out. is going to make cadvisor more resilient to the issue of docker is not available, and have some retry logic. I am going to change kubelet initialization logic a little bit to make sure docker is running before we start cadvisor.
Awesome, thank you Dawn! Are there issues or PRs I can follow to know when this is unblocked?
is one of them. is working on the second.
Change:
fi # shellcheck disable=SC2024 <del> sudo "${GO_OUT}/hyperkube" proxy  </del> <ins> sudo "${GO_OUT}/hyperkube" kube-proxy  </ins> --v="${LOG_LEVEL}"  --config=/tmp/kube-proxy.yaml  --master="https://${API_HOST}:${API_SECURE_PORT}" >"${PROXY_LOG}" 2>&1 &

Discussion:
Hyperkube supports a number of short aliases for commands, such as , , , , etc, rather than the longer , , , etc. There are comments indicating this is "unfortunate" and we still currently create these aliases in the hyperkube docker image: It'd be nice to simplify this, assuming we can find all uses of the short aliases and remove them. /kind cleanup Not sure which sig should own this, so tagging a few. /sig architecture cluster-lifecycle cli cc
interestingly, the command doesn't create the short aliases, though we also don't really use anywhere either.
I think we can just go ahead and start the deprecation cycle for this. WDYT? cc
cc as well
+1 to nuke it
/assign :wink: ok?
SGTM
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
/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 : /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 would like to work on it!
It seems like this issue was already solved in ?
I don't think the hyperkube code was changed in that PR, only the image?
Yes, thanks for your comment, can i try to fix it ?
I made a PR here: . Review/feedback/suggestions appreciated! :)
/assign /unassign
GitHub didn't allow me to assign the following users: Rand01ph.

Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /unassign 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
/remove-sig architecture cli /sig release Does anyone even still use hyperkube? Wouldn't they use kubeadm or k3s instead?
AFAIK, SAP (the company) still use hyperkube.
aks-engine deployer ( ) still uses hyperkube
Since this ticket is completed now. Can this todo be removed?
we are removing the whole thing :)
Change:
) set -x <del> /usr/local/bin/ginkgo "${ginkgo_args[@]}" /usr/local/bin/e2e.test -- --disable-log-dump --repo-root=/kubernetes --provider="${E2E_PROVIDER}" --report-dir="${RESULTS_DIR}" --kubeconfig="${KUBECONFIG}" -v="${E2E_VERBOSITY}" > >(tee "${RESULTS_DIR}"/e2e.log) ret=$? </del> <ins> /usr/local/bin/ginkgo "${ginkgo_args[@]}" /usr/local/bin/e2e.test -- --disable-log-dump --repo-root=/kubernetes --provider="${E2E_PROVIDER}" --report-dir="${RESULTS_DIR}" --kubeconfig="${KUBECONFIG}" -v="${E2E_VERBOSITY}" > >(tee "${RESULTS_DIR}"/e2e.log) && ret=0 || ret=$? </ins> set +x saveResults exit ${ret}

Discussion:
Same as an issue that occurred for v1.14.0: the failing test causes ginkgo to exit non-zero which causes the script to abort without running the routine. A recent PR to this script fixed a race but we didn't realize that now that the command was running in the foreground (and not the background) that the non-zero status would impact that script. Currently, Sonobuoy can get around this by just using the Golang based runner via . The Go-runner does not seem to have a similar vulnerability. This is going to be the default for Sonobuoy runs starting in Sonobuoy v0.16.0 if the PR gets merged. Honestly, I think that we may want to consider just removing the bash script all-together for v1.17.0 if the go runner works well for this entire cycle. See the original reporting of the issue and diagnosis here: /sig testing /area conformance /priority important-soon
/assign The PR in question that re-emerged this problem: FWIW Sonobuoy is adding an integration suite that will be able to test this going forward (soon). I think we need to fix the script (and get it cherrypicked into v1.16.x branches) I think that if the go runner proves stable over v1.16 then we default to it going forward We consider removing entirely if we think we can do that without impacting other workflows. Maybe that wont be possible due to other workflows though. cc
is probably never called due to , it can probably be fixed by adding a or before line 70.
Yes that is exactly why it is but in the past when I recommended removing/modifying the errexit code I've gotten pushback from a googler just due to convention: see Just will add something like to the lines that need this
Change:
} type testClientConfig struct { <ins> rawconfig          *clientcmdapi.Config </ins> config             *restclient.Config namespace          string namespaceSpecified bool

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!--What happened: In-cluster namespace isn't overridden by kubeconfig if the context is specified via kubectl flag. When using , the override works as expected. What you expected to happen: If I specify for a context in kubeconfig, then I expect to use as the default namespace, regardless of whatever's in . How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: supposedly fixed this issue, but not for the case where the context is specified via a command line flag (). This is because this line checks for . Environment: Kubernetes version (use ): v1.10.5 (details above) Cloud provider or hardware configuration: - OS (e.g. from /etc/os-release): - Kernel (e.g. ): - Install tools: - Others: - <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
fixed in
Change:
"k8s.io/apiserver/pkg/admission/initializer" "k8s.io/apiserver/pkg/authentication/user" "k8s.io/apiserver/pkg/authorization/authorizer" <del> "k8s.io/kubernetes/pkg/api/legacyscheme" </del> <ins> fakediscovery "k8s.io/client-go/discovery/fake" "k8s.io/client-go/restmapper" coretesting "k8s.io/client-go/testing" </ins> api "k8s.io/kubernetes/pkg/apis/core" kubeadmission "k8s.io/kubernetes/pkg/kubeapiserver/admission" <del> // Manually initialize legacy scheme to make test rest mapper work with built-in resources. // See issue #70192 for more details _ "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset" </del> ) type fakeAuthorizer struct{}

Discussion:
/kind flake /sig testing /sig auth we are injecting a restMapper into this admisson controller while in its test, the restMapper somehow become empty when we remove internal clientset/informer dependency from it (). now we come up with a walkaround in which we manually init the legacy schema via a dry import so that the built-in resources can be installed. this failing test suggests that the test is not quite correct logically.
/assign Are you up for trying to figure out how to avoid requiring the internal types?
What test does this break? Links?
link here: w/o the dry import, then will fail with output:
sure. will be looking into it
OK, setting priority so that I know this isn't a 1.13 blocker. /priority important-longterm
Change:
// parsing successful, so we now know the proper value for .Parts requestInfo.Parts = currentParts <ins> // Raw should have everything not in Parts requestInfo.Raw = requestInfo.Raw[:len(requestInfo.Raw)-len(currentParts)] </ins> // if there's another part remaining after the kind, then that's the resource name if len(requestInfo.Parts) >= 2 {

Discussion:
The apiserver proxy rewrites links to the form "/proxy/ns/default/...": But this form stopped working recently, seemingly around The "/proxy/ns/default/..." form always returns "404: Page Not Found", similar to the problem seen in If you remove "/ns/default" from the URL, it works.
/cc
I can investigate this as well.
I see the issue, sending a PR.
The proxy path needs to be built with knowledge of the apiversion of the incoming proxy request, and it needs to be updated to use the knowledge from the restmapper. This is a little trickier than I have time for right now, but it should definitely not be hardcode appending the /ns form. Not clear why this is not also caught by our test case. I can try and look at this more in the AM unless someone else wants to take a look in interim. /cc
Let me steal this one from you, I think I can fix it.
Have at it. /cc me on your PR
Sorry, I see you've already got a PR out!
No problem. I would be happy if you finished my PR relative to the commit I started. It will be a few days before I can go back to looking at this issue. I think v1beta1/v1beta2 proxy urls in go-restful need to always but the namespace scope in the path as the ultimate fix. I do want the proxy to have access to the restmapper per my PR. ----- Original Message ----- From: "Daniel Smith" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Friday, February 13, 2015 4:56:19 PM Subject: Re: [kubernetes] apiserver proxy stopped accepting namespaces () Sorry, I see you've already got a PR out! Reply to this email directly or view it on GitHub:
Any updates ?
This is breaking monitoring since it requires the proxy. Bumping up the priority to P0.
Sorry for dropping this. Working on a fix.
Change:
// If the network plugin is not ready, only start the pod if it uses the host network if rs := kl.runtimeState.networkErrors(); len(rs) != 0 && !kubecontainer.IsHostNetworkPod(pod) { <del> kl.recorder.Eventf(pod, v1.EventTypeWarning, events.NetworkNotReady, "network is not ready: %v", rs) return fmt.Errorf("network is not ready: %v", rs) </del> <ins> kl.recorder.Eventf(pod, v1.EventTypeWarning, events.NetworkNotReady, "%s: %v", NetworkNotReadyErrorMsg, rs) return fmt.Errorf("%s: %v", NetworkNotReadyErrorMsg, rs) </ins> } // Create Cgroups for the pod and apply resource parameters

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pods are synchronized by kubelet before network is ready. Synchronization in such case fails and pod is synchronized after 10 seconds. What you expected to happen: Kubelet should wait until network is ready before starting synchronizing pods. How to reproduce it (as minimally and precisely as possible): Configure cluster with Cluster Autoscaler enabled. Start pod so cluster is scaled up. In logs you might find following error: E0907 13:18:49. 972 ] Error syncing pod xxxxxx ("xxxxxxxxx(xxxxxxxxxxx)"), skipping: network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: Kubenet does not have netConfig. This is most likely due to lack of PodCIDR] Environment: Build from HEAD Cloud provider or hardware configuration: GKE
/kind bug /sig node
Change:
// _bindata is a table, holding each asset generator, mapped to its name. var _bindata = map[string]func() (*asset, error){ <ins> "translations/OWNERS":                             translationsOwners, </ins> "translations/extract.py":                         translationsExtractPy, "translations/kubectl/OWNERS":                     translationsKubectlOwners, "translations/kubectl/de_DE/LC_MESSAGES/k8s.mo":   translationsKubectlDe_deLc_messagesK8sMo,

Discussion:
/assign /cc Please ensure that every sub directory of / contains an owners file. The following sub directories do not define them: The result of this is that any PR which changes anything in api, Godeps, staging, vendor, etc will always get assigned to one of you for both the review and approval.
I recall someone also mentioning that certain files or dirs may not need approvers files. If that would help, we can add that functionality (i've already started the work)
staging and api should be easy to find owners for. may have ideas for translations. The big one is Godeps, third_party, vendor. Those are just grunt work. And figuring out criteria for approving is hard as they are a lot of code and it is unclear that things are tested well or automatically. (I'm thinking things like libraries for accessing cloud APIs). Having a dedicated team/process there might help.
I'll open some proposals for staging and API.
Godep in particular needs to be watched for things like licenses, which I have mostly been doing.
Thanks Clayton for the staging and api additions! How about if we pick two of you at random and shove them in as owners for each of the remaining directories?
What's left: translations: the kubectl specific translations is being handled by sig-cli, but the rest of the files like README and test have been handled and approved mostly by thirdparty: this is a tricky mix of stuff like forked code.. mostly handled by the likes of or for approvals. Godep/vendor: These could probably be solved by having a process to follow, and then delegating to a team in OWNERSALIASES for both folders.
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
Still relevant. /remove-lifecycle stale
Change:
was configured with a subpath. release: v1.12 file: test/e2e/storage/subpath.go <ins> - testname: VolumeAttachment, lifecycle codename: '[sig-storage] VolumeAttachment Conformance should run through the lifecycle of a VolumeAttachment [Conformance]' description: Creating an initial VolumeAttachment MUST succeed. Reading the VolumeAttachment MUST succeed with with required name retrieved. Patching a VolumeAttachment MUST succeed with its new label found. Listing VolumeAttachment with a labelSelector MUST succeed with a single item retrieved. Deleting a VolumeAttachment MUST succeed and it MUST be confirmed. Creating a second VolumeAttachment MUST succeed. Updating the second VolumentAttachment with a new label MUST succeed with its new label found. Creating a third VolumeAttachment MUST succeed. Updating the third VolumentAttachment with a new label MUST succeed with its new label found. Deleting both VolumeAttachments via deleteCollection MUST succeed and it MUST be confirmed. release: v1.30 file: test/e2e/storage/volume_attachment.go </ins>

Discussion:
[x] two weeks soak end date : 14 Mar 2024 : According to following APIsnoop query, there are six VolumeAttachment endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 7 endpoints. The e2e logs for this test are listed below. This query shows the following VolumeAttachment endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/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
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
Change:
defer watcher.Stop() done := make(chan struct{}) <del> defer close(done) </del> <ins> var wg sync.WaitGroup wg.Add(1) defer wg.Wait()   // We must wait for the waitgroup to exit before we terminate the cache or the server in prior defers defer close(done) // call close first, so the goroutine knows to exit </ins> go func() { <ins> defer wg.Done() </ins> for i := 0; i < 100; i++ { select { case <-done:

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: bazel-test-master Which test(s) are flaking: - TestWatchBookmarksWithCorrectResourceVersion Testgrid link: Reason for failure: Anything else we need to know: links to appreciated Somehow nothing seen on triage - wonder why? links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig testing
is still only reporting up to Sept 21 Other instances of non-deterministic result (NDR)
/sig api-machinery /sig storage Not 100% sure which SIG should triage the data race on which is producing non-deterministic results (NDRs) during CI can you both take a look and let me know? Many thanks, CI Signal Team Lead for 1.20 (release team)
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : 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
Looks like the bot didn't pick up the SIG tags - /sig api-machinery /sig storage
/sig scalability /remove-sig storage
I'm sending a fix
t.Fatal was getting called long after the test had exited, because the test was shutting down the framework before the goroutine had exited.
Change:
HEAPSTER_GCP_BASE_CPU="${HEAPSTER_GCP_BASE_CPU:-80m}" HEAPSTER_GCP_CPU_PER_NODE="${HEAPSTER_GCP_CPU_PER_NODE:-0.5}" <ins> # Optional: custom system banner for dashboard addon CUSTOM_KUBE_DASHBOARD_BANNER="${CUSTOM_KUBE_DASHBOARD_BANNER:-}" </ins> # Default Stackdriver resources version exported by Fluentd-gcp addon LOGGING_STACKDRIVER_RESOURCE_TYPES="${LOGGING_STACKDRIVER_RESOURCE_TYPES:-old}"

Discussion:
you this variable - PTAL
/sig gcp
Ping? I see that in all failure log messages for . Not sure if thats the cause or just an error message I can ignore?
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 /assign since I bumped into this
Change:
"os" "k8s.io/kubernetes/pkg/healthz" <del> "k8s.io/kubernetes/pkg/util" </del> "k8s.io/kubernetes/pkg/util/flag" "k8s.io/kubernetes/pkg/util/logs" "k8s.io/kubernetes/pkg/version/verflag"

Discussion:
When I tried to use the following command to build kubernetes: I encountered the following errors: I'm using Ubuntu 14.04 and the code from master branch. will submit a patch then to fix this problem.
whoa, I just landed in the exact same place, I am trying to build k8s on a CentOS7 box. Tried with removing the unused utils and works like a charm !