jiebi/CodeConvo huggingface dataset:
Change:
Expect(err).NotTo(HaveOccurred()) dirName := strings.Fields(res)[0] hostDir := "/mnt/disks/by-uuid/google-local-ssds-scsi-fs/" + dirName <del> return generateLocalTestVolume(hostDir, config, GCELocalSSDVolumeType, node) </del> <ins> // gce local ssd does not need to create a directory return &localTestVolume{ node:            node, hostDir:         hostDir, localVolumeType: GCELocalSSDVolumeType, } </ins> } func setupLocalVolumeDirectory(config *localTestConfig, node *v1.Node) *localTestVolume {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Since 8/31, these tests have started flaking, and then started failing consistently. https://k8s- https://k8s- /assign
/kind failing-test
/milestone v1.12
Does this need cherry picked back to 1.11? Still have upgrade failures with this symptom, eg: https://k8s-
No, the localssd tests are not failing in the upgrade suite
/reopen I'm going to call this one a partial fix, as we are still seeing the "Set fsGroup for local volume should not set different fsGroups for two pods simultaneously" error on a whole bunch of test suites.
Reopening 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
can you link me to other suites where it is failing?
okay "a whole bunch" was exaggerated, I apologize: https://k8s- https://k8s-
The upgrade tests are not failing with "gce-localssd", which is what this issue is addressing, so is not related. The upgrade tests issues are being tracked in /close
Closing this issue. <detailsIn response to : The upgrade tests are not failing with "gce-localssd", which is what this issue is addressing, so is not related. 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:
}) const ( <del> influxdbService      = "monitoring-influxdb" influxdbDatabaseName = "k8s" podlistQuery         = "show tag values from "cpu/usage" with key = pod_id" nodelistQuery        = "show tag values from "cpu/usage" with key = hostname" sleepBetweenAttempts = 5 * time.Second testTimeout          = 5 * time.Minute </del> <ins> influxdbService       = "monitoring-influxdb" influxdbDatabaseName  = "k8s" podlistQuery          = "show tag values from "cpu/usage" with key = pod_id" nodelistQuery         = "show tag values from "cpu/usage" with key = hostname" sleepBetweenAttempts  = 5 * time.Second testTimeout           = 5 * time.Minute initializationTimeout = 5 * time.Minute </ins> ) var (

Discussion:
The following E2E test is failing in the GCE 1.5-1.6 upgrade jobs. Please take a look and let me know ASAP if this is a 1.6 blocker or not (I think it may be a flake, but need you to confirm). https://k8s- Expected error: <*errors.errorString | 0xc421d5ef10: { s: "expected to find one replica for RC or deployment with label heapster but got 0", } expected to find one replica for RC or deployment with label heapster but got 0 not to have occurred
/assign
can you help get this looked at and triaged ASAP? Thanks.
I pinged by email. He's really the one who should look at this.
The problem seems to be not with the test itself but with Kubernetes or test framework, since the test failed on starting Heapster. I'll investigate more later today.
I haven't got time to investigate. This seems to be unrelated to monitoring itself, so any help during MTV day would be great. If not I'll try to fix this tomorrow
thanks
The problem is in , in function . The function is called immediately from , w/o waiting for system pods (heapster) to start. We should give some time for heapster to become ready, as it takes few minutes after cluster creation.
CC
thanks a lot for investigation! is going to fix it.
Change:
return describePersistentVolume(pv, events) } <ins> func printVolumeNodeAffinity(w PrefixWriter, affinity *api.VolumeNodeAffinity) { w.Write(LEVEL_0, "Node Affinity:t") if affinity == nil || affinity.Required == nil { w.WriteLine("<none>") return } w.WriteLine("") if affinity.Required != nil { w.Write(LEVEL_1, "Required Terms:t") if len(affinity.Required.NodeSelectorTerms) == 0 { w.WriteLine("<none>") } else { w.WriteLine("") for i, term := range affinity.Required.NodeSelectorTerms { printNodeSelectorTermsMultilineWithIndent(w, LEVEL_2, fmt.Sprintf("Term %v", i), "t", term.MatchExpressions) } } } } // printLabelsMultiline prints multiple labels with a user-defined alignment. func printNodeSelectorTermsMultilineWithIndent(w PrefixWriter, indentLevel int, title, innerIndent string, reqs []api.NodeSelectorRequirement) { w.Write(indentLevel, "%s:%s", title, innerIndent) if len(reqs) == 0 { w.WriteLine("<none>") return } for i, req := range reqs { if i != 0 { w.Write(indentLevel, "%s", innerIndent) } exprStr := fmt.Sprintf("%s %s", req.Key, strings.ToLower(string(req.Operator))) if len(req.Values) > 0 { exprStr = fmt.Sprintf("%s [%s]", exprStr, strings.Join(req.Values, ", ")) } w.Write(LEVEL_0, "%sn", exprStr) } } </ins> func describePersistentVolume(pv *api.PersistentVolume, events *api.EventList) (string, error) { return tabbedString(func(out io.Writer) error { w := NewPrefixWriter(out)

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?: /assign What happened: Now that it's a field, it needs a separate entry in 'kubectl describe'
Change:
b.Fatalf("op %d: invalid op %v", opIndex, concreteOp) } } <del> if err := waitUntilPodsScheduled(ctx, podInformer, b.Name(), nil, numPodsScheduledPerNamespace); err != nil { // Any pending pods must be scheduled before this test can be considered to // be complete. b.Fatal(err) } </del> <ins> // Some tests have unschedulable pods. Do not add an implicit barrier at the // end as we do not want to wait for them. </ins> return dataItems }

Discussion:
is a very useful option in scheduler perf test framework to define an operation without waiting for it to finish. However, the current testing logic still waits for all the pods in this operation to be schedulable, in the last step: the number for Pods in this operation to be schedulable This can be problematic as some case just want to generate Pods (for example, to test internal queuing or sorting behavior/latency). The following test command times out as those large-cpu Pods are expected to not fit on any node: So, given is commented as: I'm proposing to relax the semantics to not wait for the Pods to be schedulable if the operation is specified as . /sig scheduling
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
/assign WDYT?
Change:
len(nodes.Items)) } <del> ips := e2enode.CollectAddresses(nodes, v1.NodeInternalIP) </del> <ins> var family v1.IPFamily if framework.TestContext.ClusterIsIPv6() { family = v1.IPv6Protocol } else { family = v1.IPv4Protocol } ips := e2enode.GetAddressesByTypeAndFamily(&nodes.Items[0], v1.NodeInternalIP, family) </ins> clientNodeInfo = nodeInfo{ name:   nodes.Items[0].Name, nodeIP: ips[0], } <ins> ips = e2enode.GetAddressesByTypeAndFamily(&nodes.Items[1], v1.NodeInternalIP, family) </ins> serverNodeInfo = nodeInfo{ name:   nodes.Items[1].Name, <del> nodeIP: ips[1], </del> <ins> nodeIP: ips[0], </ins> } })

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: sig-network-kind-ipvs,dual,master sig-network-kind-ipvs,IPv6,master Which test(s) are failing: [x] KubeProxy should set TCP CLOSE_WAIT timeout [x] Conntrack should be able to preserve UDP traffic when server pod cycles for a NodePort Service [x] KubeProxy should resorve connection reset issue (tracking in ) Since when has it been failing: Oct 28 Testgrid link: sig-network-kind-ipvs,dual,master  Reason for failure: Both appear to be failing on missing conntrack entries ex. Anything else we need to know:
/sig network /cc /assign
I'm spinning up a kind cluster with ipv6+ipvs to see if I can replicate this test locally
/triage accepted
heh, the job was not running it, it started to run when we changed the tag I meant this test and the PR where we renamed the kube-proxy test
this one has an issue already open, and I have a PR for fixing it
reached out to me on Slack and we identified as the high priority. I have tested this locally and it fails on both IPTables and IPVS kind clusters locally. I'm digging through the cluster logs now.
I' ve logging to conntrack with level v4 recently just for these problems, try to bump your kube-proxy logging to v4
seems that there are less test failures on the IPv6 jobs, let's keep watching them :eyes: However, the dual-stack jobs are legit failures, basically because on dualstack clusters, the node has 2 internal IPs, and those tests use the internal IP for asserting some operations, and the problem is that they are picking the internalIP of the wrong IP family, hence the test fails The solution should be to add the InernalIp correspoding to the cluster primary IP familty, you can obtain it with but it seems that we have to modify the function or add a new one that returns the nodes and the corresponding ips
Hey Thanks for all the help, will look into the areas of the code and try to bump the logging.
Change:
"k8s.io/kubernetes/pkg/controller/util/node", "k8s.io/kubernetes/pkg/controller/volume/persistentvolume/util", "k8s.io/kubernetes/pkg/controller/volume/scheduling", <ins> "k8s.io/kubernetes/pkg/credentialprovider", "k8s.io/kubernetes/pkg/credentialprovider/aws", "k8s.io/kubernetes/pkg/credentialprovider/azure", "k8s.io/kubernetes/pkg/credentialprovider/gcp", "k8s.io/kubernetes/pkg/credentialprovider/secrets", </ins> "k8s.io/kubernetes/pkg/features", "k8s.io/kubernetes/pkg/fieldpath", "k8s.io/kubernetes/pkg/kubectl",

Discussion:
What happened: There is to manage import ways under but that doesn't work at our upstream CI. We can enable it by But if doing that, we will face the following error with What you expected to happen: I hope the check is always running to block invalid import ways at upstream CI system. How to reproduce it (as minimally and precisely as possible): As line into arguments.InputDirs of
/sig testing /area e2e-test-framework
Change:
fi fi # Command <del> kubectl annotate -f "${file}" annotated=true "${kube_flags[@]}" </del> <ins> # Command # We need to set --overwrite, because otherwise, if the first attempt to run "kubectl annotate" # fails on some, but not all, of the resources, retries will fail because it tries to modify # existing annotations. kubectl-with-retry annotate -f $file annotated=true --overwrite "${kube_flags[@]}" </ins> # Post-condition: mock service (and mock2) and mock rc (and mock2) are annotated if [ "$has_svc" = true ]; then kube::test::get_object_assert 'services mock' "{{${annotations_field}.annotated}}" 'true'

Discussion:
shippable flake: It seems that this test needs to retry on update failures. cc who fixed some other similar test flakes recently and might want to take a swing at this one.
cc
We discussed about it in Assigning to
Thanks . Removing team/control-plane, as team/CSI seem to have this in hand.
Aha, my PR was also hit by this flake just now. I'll try to fix this tmr.
has the same problem.
Change:
}) } <ins> postTimeoutCh := make(chan struct{}) </ins> ts := httptest.NewServer( withDeadline( WithTimeout(

Discussion:
Unit test in package flakes there is a race condition between the go routine that executes the request handler and the timeout go routine that waits for the handler to finish /sig api-machinery
/assign
I have a PR in the works
should fix it, I can easily reproduce it with the PR, the flake is not reproducible any more cc
/triage accepted
Change:
klog.Errorf("detach azure disk: disk %s not found, diskURI: %s", diskName, diskURI) } <del> newVM := compute.VirtualMachine{ Location: vm.Location, </del> <ins> newVM := compute.VirtualMachineUpdate{ </ins> VirtualMachineProperties: &compute.VirtualMachineProperties{ HardwareProfile: vm.HardwareProfile, StorageProfile: &compute.StorageProfile{

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Instead of using the VM CreateOrUpdate () function of the Azure Go SDK, use the VM Update function () in the azureclient () Why is this needed: Currently, the Azure Cloud Provider is using the VM CreateOrUpdate call when e.g. detach/attaching disks to a VM. In some scenarios, this will re-create a VM that was deleted by an external application. This can lead to orphaned VMs or blocked resources. The Update function will only update an existing VM and will fail if the VM does not exist.
/sig azure
/assign
/sig cloud-provider
Could you describe more about the scenarios? Have you noticed such issues? I wonder adding etags to the API call could help to prevent this?
If you have an application that maintains your K8s clusters, e.g. takes care of OS update/patching. If the application wants to patch the OS of a worker node, it would drain the node first. If draining times out, it will go ahead and delete the VM anyway. But K8s might still be detaching disks. These detach operations, because they use CreateOrUpdate, will recreate the VM. Is there a reason why you would want to create a VM i.e. why CreateOrUpdate is required and Update would not work? AFAIK, Azure Compute RP does not support etags.
that sounds reasonable, thanks change to use function would be safer since it's only detach/attach disk operation. I will do that.
thanks for the information. Reasonable enough. /assign
/milestone v1.16
BTW, the reason why we only use func in the beginning is that Azure Compute go sdk did not provide a func at that time...
Great. Thanks!
Change:
} } <del> select { case <-execFuncDone: case <-time.After(10 * time.Millisecond): t.Fatalf("%d: timed out waiting for execFunc to complete", i) } </del> <ins> <-execFuncDone </ins> } }

Discussion:
this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.
Change:
# Metadata for driving the build lives here. META_DIR := .make <del> # Our build flags. # TODO(thockin): it would be nice to just use the native flags.  Can we EOL #                these "wrapper" flags? KUBE_GOFLAGS := $(GOFLAGS) KUBE_GOLDFLAGS := $(GOLDFLAGS) KUBE_GOGCFLAGS = $(GOGCFLAGS) </del> <ins> ifdef KUBE_GOFLAGS $(info KUBE_GOFLAGS is now deprecated. Please use GOFLAGS instead.) ifndef GOFLAGS GOFLAGS := $(KUBE_GOFLAGS) unexport KUBE_GOFLAGS else $(error Both KUBE_GOFLAGS and GOFLAGS are set. Please use just GOFLAGS) endif endif </ins> # Extra options for the release or quick-release options: KUBE_RELEASE_RUN_TESTS := $(KUBE_RELEASE_RUN_TESTS)

Discussion:
We should just use GOFLAGS
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 contributor-experience
/assign
Change:
} type ServiceController struct { <del> cloud       cloudprovider.Interface kubeClient  client.Interface clusterName string balancer    cloudprovider.TCPLoadBalancer zone        cloudprovider.Zone cache       *serviceCache </del> <ins> cloud            cloudprovider.Interface kubeClient       client.Interface clusterName      string balancer         cloudprovider.TCPLoadBalancer zone             cloudprovider.Zone cache            *serviceCache eventBroadcaster record.EventBroadcaster eventRecorder    record.EventRecorder </ins> } // New returns a new service controller to keep cloud provider service resources // (like external load balancers) in sync with the registry. func New(cloud cloudprovider.Interface, kubeClient client.Interface, clusterName string) *ServiceController { <ins> broadcaster := record.NewBroadcaster() broadcaster.StartRecordingToSink(kubeClient.Events("")) recorder := broadcaster.NewRecorder(api.EventSource{Component: "service-controller"}) </ins> return &ServiceController{ <del> cloud:       cloud, kubeClient:  kubeClient, clusterName: clusterName, cache:       &serviceCache{serviceMap: make(map[string]*cachedService)}, </del> <ins> cloud:            cloud, kubeClient:       kubeClient, clusterName:      clusterName, cache:            &serviceCache{serviceMap: make(map[string]*cachedService)}, eventBroadcaster: broadcaster, eventRecorder:    recorder, </ins> } }

Discussion:
If a LoadBalancer cannot be created (e.g. quota limit hit), there is currently no way to know why other than reviewing the logs (?). We could put an status message / object into LoadBalancerStatus.
We could make an event for this too Justin Santa Barbara < :
+1 for event
I think that is reasonable, but we need to be careful how we define it. Event also sounds good. , Justin Santa Barbara < :
I'm in favor of status as well as an event. The pattern I recommend is an array of conditions, similar to NodeCondition, where each contains at least a Status, Reason, and Message.
+1 for an event. I'd argue this is important enough for usability that we should get it into v1.
How often does this failure mode occur?
I unfortunately don't have stats, but it can happen for a handful of reasons. I think these are the most likely: Cloud provider unavailability/errors Ran out of quota from the cloud provider The cluster is using a cloud provider that doesn't support external load balancers I expect the third one is most common by far. We could perhaps move that into the API object validation rather than writing events to handle that particularly case, but using events would solve all the cases together.
Change:
"//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/runtime:go_default_library", "//vendor/k8s.io/apimachinery/pkg/runtime/serializer:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/runtime/serializer/json:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/util/runtime:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/uuid:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/wait:go_default_library",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: We face But there is no way to generate default config file How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version 1.9.2
I'll take a look it /sig scheduling
/assign
Hi, same issue with controller-manager
Any updates here? , and don't have this flag. Is it even will be supported?
/cc
if not set, component should be use default value; why we'd like to dump all default config?
Because the documentation on the config file format is either nonexistent or difficult to find. If the program itself can generate a template, that fulfills (most of) the need for documentation of the format.
+1 for this, from my expirence, add an option to write the default config is really helpful.
/assign
also in 1.10
Deprecating all flags, prompting folks to use config files in advance is great, except when there's no documentation nor example anywhere. That means that we can't actually migrate to the new settings, and I can't seem to find clear alpha/beta/stable status for the new config file spec, nor timeline for the removal. It is also pretty confusing that the scheduler expects us to use a config file, but the controller-manager does not?
This issue indeed applies to kube-controller-manager. And there should already had deprecation policy.
According to , the flag will be available in . Since I can't find any reference online to an example config file, perhaps one could be provided or linked to here?
will you be able to pick my patch and generate a config file? I do not get my devbox handy so can only post here until Monday.
Change:
framework.Skipf("Environment does not support getting controller-manager metrics - skipping") } <ins> ginkgo.By("Geting default storageclass") defaultClass, err := c.StorageV1().StorageClasses().Get(defaultScName, metav1.GetOptions{}) framework.ExpectNoError(err, "Error getting default storageclass: %v", err) pluginName := defaultClass.Provisioner </ins> controllerMetrics, err := metricsGrabber.GrabFromControllerManager() framework.ExpectNoError(err, "Error getting c-m metrics : %v", err) <del> storageOpMetrics := getControllerStorageMetrics(controllerMetrics) ginkgo.By("Creating an invalid storageclass") defaultClass, err := c.StorageV1().StorageClasses().Get(defaultScName, metav1.GetOptions{}) framework.ExpectNoError(err, "Error getting default storageclass: %v", err) </del> <ins> storageOpMetrics := getControllerStorageMetrics(controllerMetrics, pluginName) </ins> invalidSc = &storagev1.StorageClass{ ObjectMeta: metav1.ObjectMeta{

Discussion:
Which jobs are flaking: () () Which test(s) are flaking: Reason for failure: Timeout: Anything else we need to know: This test flaking about 10% of the time in this job. /sig storage /kind flake /priority important-soon cc
/remove-kind failing-test
/assign
I noticed one issue with the test is that it's not filtering metrics by plugin name. So it will just count the last plugin's metric. I'm not sure if the metrics collected are in any sorted order or not. If not, then when you have a suite that runs multiple plugins, then you might be pulling from the wrong metric.
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
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
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
/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
/remove-lifecycle rotten
still very prevalent in sig-release dashboards
I have pushed which should hopefully fix this.
Also PR against 1.17 branch -