Elasticsearch: Vérifier l'espace disque disponible avant de commencer une construction

Créé le 19 sept. 2016  ·  3Commentaires  ·  Source: elastic/elasticsearch

Ce serait super sympa de vérifier avec gradle avant de commencer les tests (ou à chaque exécution quelle que soit la tâche) que nous avons suffisamment d'espace disque dur (plus de 10%).

Sinon, certains tests peuvent échouer.

Par exemple, j'exécutais gradle check pour un PR non lié à netty3 et il échouait toujours dans le module netty3 avec :

  2> REPRODUCE WITH: gradle :modules:transport-netty3:integTest -Dtests.seed=E0B565B5C6B00017 -Dtests.class=org.elasticsearch.http.netty3.Netty3ClientYamlTestSuiteIT -Dtests.method="test {yaml=indices.get_alias/10_basic/Get aliases via /{index}/_alias/name,name}" -Dtests.security.manager=true -Dtests.locale=ar-KW -Dtests.timezone=CET
ERROR   30.1s | Netty3ClientYamlTestSuiteIT.test {yaml=indices.get_alias/10_basic/Get aliases via /{index}/_alias/name,name} <<< FAILURES!
   > Throwable #1: java.lang.RuntimeException: Failure at [indices.get_alias/10_basic:5]: listener timeout after waiting for [30000] ms
   >    at __randomizedtesting.SeedInfo.seed([E0B565B5C6B00017:68E15A6F684C6DEF]:0)
   >    at org.elasticsearch.test.rest.yaml.ESClientYamlSuiteTestCase.executeSection(ESClientYamlSuiteTestCase.java:327)
   >    at org.elasticsearch.test.rest.yaml.ESClientYamlSuiteTestCase.test(ESClientYamlSuiteTestCase.java:300)
   >    at java.lang.Thread.run(Thread.java:745)
   > Caused by: java.io.IOException: listener timeout after waiting for [30000] ms
   >    at org.elasticsearch.client.RestClient$SyncResponseListener.get(RestClient.java:615)
   >    at org.elasticsearch.client.RestClient.performRequest(RestClient.java:212)
   >    at org.elasticsearch.client.RestClient.performRequest(RestClient.java:185)
   >    at org.elasticsearch.test.rest.yaml.ClientYamlTestClient.callApi(ClientYamlTestClient.java:227)
   >    at org.elasticsearch.test.rest.yaml.ClientYamlTestExecutionContext.callApiInternal(ClientYamlTestExecutionContext.java:107)
   >    at org.elasticsearch.test.rest.yaml.ClientYamlTestExecutionContext.callApi(ClientYamlTestExecutionContext.java:72)
   >    at org.elasticsearch.test.rest.yaml.section.DoSection.execute(DoSection.java:128)
   >    at org.elasticsearch.test.rest.yaml.ESClientYamlSuiteTestCase.executeSection(ESClientYamlSuiteTestCase.java:325)
   >    ... 38 more

Quand j'ai regardé modules/transport-netty3/build/cluster/integTest\ node0/elasticsearch-6.0.0-alpha1-SNAPSHOT/logs/modules_transport-netty3_integTest.log , j'ai vu :

[2016-09-19T10:32:20,078][WARN ][o.e.c.r.a.DiskThresholdMonitor] [tofpR8o] high disk watermark [90%] exceeded on [tofpR8o_Tv-QZ9t2AWtjug][tofpR8o][/Users/dpilato/Documents/Elasticsearch/dev/es-gradle/elasticsearch/modules/transport-netty3/build/cluster/integTest node0/elasticsearch-6.0.0-alpha1-SNAPSHOT/data/nodes/0] free: 2.9gb[0.6%], shards will be relocated away from this node

J'ai cependant 3 Go d'espace disque disponible.

Donc si nous pouvons échouer ou avertir au début de nos tests d'intégration, cela permettrait d'identifier plus rapidement la source du "problème".

:DeliverBuild Delivery

Commentaire le plus utile

Je ne pense pas que nous devrions ajouter des choses comme ça à la construction. La vérification ne serait pas fiable car elle est sujette à des problèmes d'heure de vérification et d'heure d'utilisation, et 90 % n'est probablement même pas la bonne limite à partir d'une version propre (parce que les artefacts, les journaux et un tas d'autres choses sera créé en poussant l'utilisation du disque à plus de 90 % avant que les tests dépendants ne soient exécutés ici).

La bonne chose à faire lorsqu'un test d'intégration échoue est de lire les journaux et cela montrera le problème, comme vous l'avez fait ici.

Tous les 3 commentaires

Je ne pense pas que nous devrions ajouter des choses comme ça à la construction. La vérification ne serait pas fiable car elle est sujette à des problèmes d'heure de vérification et d'heure d'utilisation, et 90 % n'est probablement même pas la bonne limite à partir d'une version propre (parce que les artefacts, les journaux et un tas d'autres choses sera créé en poussant l'utilisation du disque à plus de 90 % avant que les tests dépendants ne soient exécutés ici).

La bonne chose à faire lorsqu'un test d'intégration échoue est de lire les journaux et cela montrera le problème, comme vous l'avez fait ici.

Je ferme ceci, mais n'hésitez pas à rouvrir @dadoonet si vous pensez le contraire.

Je suis d'accord avec cette réponse. Je disais juste que "c'est bien d'avoir". Je peux totalement vivre sans ça.

Cette page vous a été utile?
0 / 5 - 0 notes