Docker substrate

Nodes Duniter-v2s
1

Hello,

Comme expliqué dans ce commentaire j’ai créé une image Docker pour le POC lc-core-substrate.
Mais je tombe sur un os : bien que ça fonctionne sans problème sur mon PC, ça plante dès le démarrage lorsque je le lance sur mon serveur dédié :

$ docker run --rm -it --entrypoint /bin/sh lc-core-substrate
# lc-core
Illegal instruction (core dumped)

J’ai essayé d’ajouter cette option de compilation Rust -C target-arch=bonnell où bonnell correspond à la génération de processeur du serveur (*). Sans plus de succès. Le PC sur lequel ça marche a un skylake.

Est-ce que ce type d’erreur parle à quelqu’un ?

Sinon, @elois, OK pour avoir une branche sur le dépôt où je pourrais poser mon travail.

(*) cat /sys/devices/cpu/caps/pmu_name

2

Je viens de te donner les droits sur le dépot, pousse déjà une branche que je puisse utiliser moi même l’image docker et essayer de reproduire ton problème :slight_smile:

1 Like
3

C’est poussé dans la branche docker.

4

Peut tu essayer sans alpine, dans ure debian-slim à la place par exemple, je soupçonne que le problème vienne de la

EDIT: aussi le vois que tu n’ouvres qu’un seul port, pour rpc ws, il faudra en ouvrir 4 pour la prod:

  • rpc
  • rpc ws
  • p2p
  • telemetry
5

J’y croyais aussi. Mais j’ai le même souci en partant d’une Debian. J’ai fait le test avant de poster.

1 Like
6

Petit update sur ce sujet.

J’ai ouvert un ticket upstream pour l’erreur ‹ Illegal instruction ›, et ils ont été très réactifs et efficaces. Un build de node-template depuis la branche master du dépôt paritytech/subtrate fonctionne correctement sur mon serveur maintenant.

@elois il faudra rebaser lorsque le fix aura été intégré au dépôt substrate-developer-hub/substrate-node-template.

EDIT - Est-il possible en attendant de forcer l’utilisation de rocksdb 0.17.0 via une directive patch dans Cargo.toml ? Je ne sais pas faire.

5 Likes
7

Merci beaucoup @Pini pour cette investigation, comme ils le disent ce sera réglé dans la release mensuelle courant août, on mettra à jour les dépendances substrate à ce moment la :slight_smile:

8

Hello, la release d’août est dispo.

3 Likes
9

Cool, je maj ce we :slight_smile:

1 Like
10

@elois sauf erreur, je vais avoir besoin de cette maj pour tester Hydra :slightly_smiling_face:

11

@Pini ce que j’en ai compris c’est que l’image docker fonctionnais déjà, c’est juste sur une architecture spécifique qu’il y avait un bug, c’est bien ça ?
Aussi, je ne trouve pas ta branche, tu n’as pas pushé le dockerfile ?

@slaivyn a moins d’être sur l’architecture qui pose problème, l’image docker devrait déjà fonctionner chez toi, peut tu voir ça avec @Pini ? Merci :slight_smile:

12

ah, ok ! J’ai lu un peu trop vite le message initial…
J’ai trouvé une branche « docker » contenant le Dockerfile ici : Files · docker · nodes / rust / Duniter v2S · GitLab
C’est pas ça ?
Du coup je vais tester ça, merci !
(et je vois la suite avec @Pini si besoin)

1 Like
13

Si c’est bien ça, je ne trouvais pas car je cherchai dans les MR, et @Pini n’a pas créé de MR associée :sweat_smile:

14

En effet, pas fait de MR. Je voulais que ça marche sur mon serveur avant. Et ensuite je gérerai les ports.

1 Like
15

Prends plutôt l’habitude de créer la MR de suite, tu peux la mettre en mode Draft pour empêcher qu’elle soit mergée trop tôt :wink:
Tu peux même créer une MR avant même d’avoir commencé, c’est une bonne !

Bon j’ai enfin trouvé du temps pour travailler sur la maj ce soir, c’est mergé, @Pini ton image docker devrais fonctionner sur ton serveur maintenant :slight_smile:

16

@pini, @elois pour gérer les MR et savoir qui attend quoi nous avons, avec @Moul sur DuniterPy, une procédure qui fonctionne, en utilisant les statuts Assignee et Reviewer de la MR.

Je me permet de vous la proposer :

  • Seul l’auteur de la MR change les statuts (sauf exceptions décidées par le mainteneur).
  • Il se met Assignee tant qu’il ne veut pas que la MR soit mergée.
  • Quand il estime que la MR est prête pour une revue, il attribut le statut Reviewer à une personne (au mainteneur en général), qui reçoit alors un email automatique.
  • Quand il estime que la MR est prête pour être mergée, il attribut le statut Assignee à une personne (au mainteneur en général), qui reçoit alors un email automatique, ou bien il merge lui-même si il est le mainteneur.

Hope it helps.

3 Likes
17

Une MR à l’état brouillon, c’est une branche. Quel intérêt peut-il y avoir de systématiquement créer une MR alors que la branche n’est pas prête, ou quasi prête ? Ça fait double emploi et ça noie les vraies MR dans la masse.

S’il s’agit juste de retrouver facilement un travail en cours, alors chercher dans les branches existantes ne devrait pas être plus difficile que de chercher dans les MR.

P.S. : si un admin veut bien déplacer ce sous-thread, merci d’avance.

18

Dans l’UI de gitlab on trouve plus facilement les MR que les branches. Et puis des fois on à des branches techniques qui n’ont pas vocation à être mergées, ou des anciennes branches pas supprimées.
La liste des MR permet donc d’avoir une vue des travaux en cours, pas la liste des branches.
De plus, une MR peut prendre un titre et une description, permettant de mieux comprendre de quoi il s’agit, ce que est plus compliqué avec un nom de branche.

Non ça ne les noies pas, car on peut lister uniquement les MR Draft ou non Draft avec les filtres de gitlab: Merge requests · nodes / rust / Duniter v2S · GitLab

Je vais le préciser dans contribute ou quelque part, mais j’aimerais bien que tu prennes l’habitude de créer une MR dès le départ, l’idéal c’est même de passer par le bouton «create merge request» sur l’issue.

19

J’ai essayé de créer l’image docker localement avec

docker build -f docker/Dockerfile .

et après un long moment de compilation Rust j’ai l’erreur

  running: "cmake" "/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/prost-build-0.10.4/third-party/protobuf/cmake" "-Dprotobuf_BUILD_TESTS=OFF" "-DCMAKE_INSTALL_PREFIX=/root/target/release/build/prost-build-99aabf48ca17bb3a/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Debug"

  --- stderr
  thread 'main' panicked at '
  failed to execute command: No such file or directory (os error 2)
  is `cmake` not installed?

  build script failed, must exit now', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.46/src/lib.rs:974:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
The command '/bin/sh -c test -x build/duniter ||     (         CARGO_PROFILE_RELEASE_LTO="true"             cargo build --release -j $threads &&         mkdir -p build &&         mv target/release/duniter build/     )' returned a non-zero code: 101

Que vient faire cmake ici ? N’est-il pas censé être dans l’image docker qui compile Duniter ? Pourquoi y a-t-il besoin de compiler Duniter dans une image docker alors que j’ai déjà compilé Duniter en local ? Je ne connais rien à Docker mais j’aimerais bien apprendre à publier une image Docker quand la CI est indisponible.

@Pini si tu es toujours dans les parages, je veux bien être formé un minimum à Docker, quand est-ce qu’on peut s’appeler ?

20

CMake is the build system use in this case to build Rust code.
Interesting that it’s missing in your case in the build image. I remember it to be a dependency last time I build Duniter-v2s. Something might have changed in the image or somewhere.

1 Like