jiebi/CodeConvo huggingface dataset:
Change:
// Interface is an abstract interface for testability.  It abstracts the interface to cAdvisor. type Interface interface { <ins> Start() error </ins> DockerContainer(name string, req *cadvisorApi.ContainerInfoRequest) (cadvisorApi.ContainerInfo, error) ContainerInfo(name string, req *cadvisorApi.ContainerInfoRequest) (*cadvisorApi.ContainerInfo, error) SubcontainerInfo(name string, req *cadvisorApi.ContainerInfoRequest) (map[string]*cadvisorApi.ContainerInfo, error)

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:
securityRuleIDTemplate      = "/subscriptions/%s/resourceGroups/%s/providers/Microsoft.Network/networkSecurityGroups/%s/securityRules/%s" ) <ins> var providerIDRE = regexp.MustCompile(`^` + CloudProviderName + `://(.+)$`) </ins> // returns the full identifier of a machine func (az *Cloud) getMachineID(machineName string) string { return fmt.Sprintf(

Discussion:
This is required to make Cloud Controller Manager operational on the various clouds that Kubernetes runs on. We have already PRs for the following clouds: GCE - AWS - Azure - OpenStack - The following clouds still need to be addresses: CloudStack Mesos OVirt Photon Rackspace vSphere If anyone is interested in contributing to this effort, please ping me directly (on kubernetes slack or through email)
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 and label list
/sig cluster-lifecycle
cc:
I will take care of the vSphere and Photon.
I will take care of the Rackspace.
Merging for OpenStack
Reposting I am trying to use my custom out-of-tree cloud provider with Kubernetes. But I noticed that kubelet calls apis like with empty for cloud provider. Digging in the code for 1.7 branch, I see that is null for cloud-providers. As a result returns empty string. As a result, ByID() methods don't work for cloud providers since is not set.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
g := mounter.(*gitRepoVolumeMounter) g.exec = fake <del> g.SetUp(volume.MounterArgs{}) </del> <ins> err := g.SetUp(volume.MounterArgs{}) if err != nil { allErrs = append(allErrs, err) } </ins> if fake.CommandCalls != len(expecteds) { allErrs = append(allErrs,

Discussion:
Apply this patch: Then run: make test WHAT=./pkg/volume/git_repo The test fails: Test should pass. See above. The full loop is: The first problem is that fakeOutputs is capturing , so all the funcs on that list use the from the final iteration, not the one from the iteration with the [1] == "clone". But then this problem appears to be covering up a different problem in the test scenarios themselves. I looked at it for a little bit but I haven't puzzled out what the test is trying to do exactly. Hopefully someone with more knowledge of the test can take a look. It seems like a buggy test, accidentally passing due to this other loopvar sharing bug. HEAD N/A N/A N/A N/A N/A
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 storage /priority important-soon /cc Thanks for the report and the detailed explanation
/assign
I wonder if it could be beneficial to invest some time and effort to identify a maximum of loops that contain the loopvar sharing bug maybe with comment and a todo ?
Change:
minion_index = n+1 minion_ip = $minion_ips[n] <del> minion.vm.provision "shell", run: "always", path: "#{ENV['KUBE_TEMP']}/minion-start-#{n}.sh" </del> <ins> if ENV['KUBE_TEMP'] then script = "#{ENV['KUBE_TEMP']}/minion-start-#{n}.sh" minion.vm.provision "shell", run: "always", path: script end </ins> minion.vm.network "private_network", ip: "#{minion_ip}" minion.vm.hostname = "#{ENV['INSTANCE_PREFIX']}-minion-#{minion_index}" end end end

Discussion:
The Vagrantfile requires that ENV['KUBE_TEMP'] is set. If it is not, any vagrant command will fail as the file cannot be parsed. The error received is: This is contrary to the suggested method of interaction in the documentation found at which says:
Looking at the scripts, this temp directory is set on script run and cleaned up on EXIT by a trap. I've wrapped a conditional around the provision statement which allows the other commands to work, but outputs a warning that the vm will not have a provisioner set. Pull req incoming.
Cc me on your PR and I will review. I have been swamped on other topics so it's possible something regressed.
Change:
"k8s.io/apimachinery/pkg/runtime/schema" utilerrors "k8s.io/apimachinery/pkg/util/errors" "k8s.io/cli-runtime/pkg/genericclioptions" <ins> discovery "k8s.io/client-go/discovery" </ins> authorizationv1client "k8s.io/client-go/kubernetes/typed/authorization/v1" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" describeutil "k8s.io/kubernetes/pkg/kubectl/describe/versioned"

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 you expected to happen: if returns true I expect to be able to perform the action without issue. Note in this case my service user has a rolebinding in a single namespace (and that is also what my kubecontext is set to.) if I change my default to a different namespace then the command returns false How to reproduce it (as minimally and precisely as possible): create a namespace (test) create a service account in that namespace create a role that gives get list and watch permissions to create a rolebinding from that role to the service account. Anything else we need to know?: this is special because namespaces are not scoped to a namespace. if you replace the command with then you get the exepcted result however this breaks the path of least suprise. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig auth
asks the authorization system if the given verb can be performed on the given noun at the given scope. It does not interpret whether the resource exists at that scope. We could warn if we find the specified resource and it does not exist at the specified scope (just like we warn if you ask about a resource that we can't find), but we would still interrogate the authorization system and return the results as we do today. /kind feature /remove-kind bug
/cc
Change:
// Dump debug information if the error was nil. if err == nil { // Collect pod logs when we see a failure. <del> logs, logErr := e2epod.GetPodLogs(f.ClientSet, f.Namespace.Name, podClient.Name, fmt.Sprintf("%s-container", podClient.Name)) </del> <ins> logs, logErr := e2epod.GetPodLogs(f.ClientSet, f.Namespace.Name, podClient.Name, "client") </ins> if logErr != nil { framework.Failf("Error getting container logs: %s", logErr) }

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: In tests, always fails when the tests fail, with the error: . This is the message indicating that APIServer responds 400 code. What you expected to happen: Container logs should be collected correctly if tests fail. How to reproduce it (as minimally and precisely as possible): a NetworkPolicy test to make it fail and run it, or run NetworkPolicy tests with a CNI that doesn't implement NetworkPolicy. the tests fail, all attempts to get container logs will fail like the following. Anything else we need to know?: Environment: Kubernetes version (use ): 16.3 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 testing /assign
/remove-sig testing /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
numVolumes++ allErrs = append(allErrs, validateAzureFile(source.AzureFile, fldPath.Child("azureFile"))...) } <ins> if source.VsphereVolume != nil { if numVolumes > 0 { allErrs = append(allErrs, field.Forbidden(fldPath.Child("vsphereVolume"), "may not specify more than 1 volume type")) } else { numVolumes++ allErrs = append(allErrs, validateVsphereVolumeSource(source.VsphereVolume, fldPath.Child("vsphereVolume"))...) } } </ins> if numVolumes == 0 { allErrs = append(allErrs, field.Required(fldPath, "must specify a volume type")) }

Discussion:
vSphere volume spec fails with the following error, as its not been in api/validation. "spec.volumes[0]: Required value: must specify a volume type" Fixed in PR
Change:
// Each bind address below is a separate test case bindAddresses := []string{ "0.0.0.0", <del> "2001:db8::1", </del> <ins> "::", </ins> } for _, addr := range bindAddresses { options, err := NewOptions()

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Upon code inspection, found that kube-proxy server takes into consideration a bind address of 0.0.0.0 (IPv4), but does not check for a bind address of :: (all-zeros IPv6) when calculating its node IP. What you expected to happen: IPv6 address "::" should be taken into consideration when calculating node IP. How to reproduce it (as minimally and precisely as possible): Code inspection. Anything else we need to know?: Environment: Kubernetes version (use ): Latest master Cloud provider or hardware configuration**: VirtualBox cluster, Ubuntu 16.04.1 host, CentOS 7 guests OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /sig network
Change:
definitions MUST be published for custom resource definitions. release: v1.16 file: test/e2e/apimachinery/crd_publish_openapi.go <ins> - testname: Discovery, confirm the PreferredVersion for each api group codename: '[sig-api-machinery] Discovery should validate PreferredVersion for each APIGroup [Conformance]' description: Ensure that a list of apis is retrieved. Each api group found MUST return a valid PreferredVersion unless the group suffix is example.com. release: v1.19 file: test/e2e/apimachinery/discovery.go </ins> - testname: Event, delete a collection codename: '[sig-api-machinery] Events should delete a collection of events [Conformance]' description: A set of events is created with a label selector which MUST be found

Discussion:
] 20 July 2020 [x] Two weeks soak end date: 3 August 2020 According to this APIsnoop query, there are still an endpoint which is untested. Get a list of all group /apis Iterate through list Query each endpoint List the PreferredVersion for the endpoint 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 15 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/retitle Write checkAPIGroupPreferredVersion Test +Promote - +16 Endpoint coverage
/reopen Merged /assign Ready for creation of Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged /assign Ready for creation of Promotion PR 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:
// Waits for specified PD to to detach from specified hostName func waitForPDDetach(diskName, hostName string) error { if framework.TestContext.Provider == "gce" || framework.TestContext.Provider == "gke" { <ins> framework.Logf("Waiting for GCE PD %q to detach from node %q.", diskName, hostName) </ins> gceCloud, err := getGCECloud() if err != nil { return err

Discussion:
PD E2E tests have very aggressive clean up routine that does not wait for volumes to safely detached. After the test completes, the test cleanup routine unilaterally detaches the PD (instead of waiting for k8s to do it cleanly). Although this does not cause the test to fail, it results in errors in the kernel logs: We should modify these tests to wait for k8s to safely detach the disk.
Change:
NODE_INSTANCE_PREFIX="${INSTANCE_PREFIX}-minion" NODE_TAGS="${NODE_TAG}" <ins> NODE_NETWORK="${NETWORK}" </ins> ALLOCATE_NODE_CIDRS=true PREEXISTING_NETWORK=false

Discussion:
The "Services should be able to create an internal type load balancer [Slow]" e2e test is failing on our 2k-node gce clusters - https://k8s- with the following error: We're using custom subnets for our large cluster tests, and seems like the glbc controller is not able to handle them. cc
Seems similar to Assigning to you as you seem to have the context already :) Also, is this expected to be fixed in 1.8 timeframe?
doesn't set the necessary variables for the GCE cloud provider. Will throw you a PR.
Cool - thanks a lot!
Ref
I see the last test on 09/09 failed, but I can't see the build log due to exceeding memory. Any other way I can see the log, /reopen
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/network sig/scalability: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
nevermind - went directly to raw log.
Friendly ping. This e2e is still failing (https://k8s-) and it's part of release-blocking suite.
/close
Change:
imageGCPolicy ImageGCPolicy, diskSpacePolicy DiskSpacePolicy, cloud cloudprovider.Interface, <ins> autoDetectCloudProvider bool, </ins> nodeLabels map[string]string, nodeStatusUpdateFrequency time.Duration, osInterface kubecontainer.OSInterface,

Discussion:
It appears that the kubelet will detect and use the cloud provider as detected by cadvisor thus overriding the cloud provider passed in at runtime: This will break our private cloud configuration where we do not use our cloud provider's load balancing and instead use our own load balancing tier. In my opinion, the cloud provider specified at kubelet runtime should be respected for the node. Am I reading this correctly? Any thoughts on how to handle this properly? Thank you!
If you specify any cloud provider through flags, it will be used by kubelet (see ). It's only when you don't specify any cloud provider that kubelet will detect the cloud provider from the machine info, as described by the comment.
that's exactly my situation, I want to run in our private cloud environment without any of the cloud integration. If I specify cloud-provider="" at runtime it will get overridden.
Ah I see. I guess specifying an empty string is the same as not specifying any cloud provider. This auto-detection feature was introduced by /cc the author and reviewer to see if this is an intended behavior:
Legitimate concern. I'm posting a fix. Do you consider this to be a regression or are you just getting started with k8s.
I am sorry, This was not the original intention. We can keep the auto detection with a flag, or make a flag to ask kubelet not to do it. Unless there is a way to see if the variable was assigned to that I missed. I can post a fix tomorrow if it won't exit by then.
Thank you. We're running on 1.2.4 and won't be running on 1.3 for a few months yet anyways and was just testing to look for future issues when I found this.
I assigned this issue to you since , and I can't assign this to anyway :-)
Thanks for testing our 1.3 release candidate, and reporting this regression to us. We are including the fix to 1.3.
Change:
// rejectForwardingRedirects is whether to allow to forward redirect response rejectForwardingRedirects bool <ins> // tracerProvider is used to wrap the proxy transport and handler with tracing tracerProvider tracing.TracerProvider </ins> } // Complete fills in any fields not set that are required to have valid data. It's mutating the receiver.

Discussion:
Extension API servers do not currently receive the header when requests are proxied through kube-aggregator, so spans are not linked properly. Traces from the extension API sever should be linked to the parent in kube-aggregator. tracing for kube-apiserver tracing for sample-apiserver and aggregate it to kube-apiserver a request to kube-apiserver for one of the resources from sample-apiserver sample-apiserver traces will not be linked to the kube-apiserver traces No response <detailsThis problem currently exists on . </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
Change:
// Run the tests runTopologyManagerPolicySuiteTests(f) } <del> // restore kubelet config setOldKubeletConfig(f, oldCfg) // Delete state file to allow repeated runs deleteStateFile() </del> }) ginkgo.It("run Topology Manager node alignment test suite", func() {

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-node-kubelet-serial node-kubelet-serial job Which test(s) are failing: Hard to tell, but everything at one point or another. Since when has it been failing: A month or two, by recollection. would indicate several years... ci-kubernetes-node-kubelet-serial | failing_days | 992 Testgrid link: Reason for failure: Hard to tell, some is timeout, but I think timeouts due to test failures. Anything else we need to know: Nothing consistent about the failures that I can tell besides timeouts. This is the only place these serial tests are running.
/sig node
/cc
I will take a look at what happens with the serial lane.
So the kubelet failed to restart because of I think it can be related to the topology manager scope PR, I will dig into the code tomorrow. FYI
It actually looks like it was introduced by: With the same issue reported here: And Alexey has a fix for it here (I haven't reviewed it):
Thanks for the update.
Some of these failures are definitely due to , which is causing tests to fail since pods aren't terminating in time. See e.g.
/assign
Under the latest run, I saw that the kubelet failed to restart because of The problem that one of the topology manager tests failed in the middle and did not remove the state file, I can not guarantee that it a single problem, but let's start from it.