OK, tant pis pour les doublons créés avec les tags, ça devait arriver.
Je suis d’avis qu’on merge cette branche pour clore le sujet.
1 Like
Fait.
Reste la question du sort de la branche network/gtest-1100.
Le rebase sur master entraîne plein de conflits sur des commits intermédiaires, là où le merge de master sur cette branche n’entraîne aucun conflit.
Qu’est-ce qu’on en fait au final, on merge sur master ou on n’en fait rien ?
Si on n’en fait rien, il faudra nettoyer master des artefacts gdev et gtest obsolètes.
Je suis d’avis de merger, mais à vous de voir ce process.
Pour en avoir discuté avec @HugoTrentesaux il y a quelques jours, on semble à peu près tomber d’accord sur la pertinence de merger ces branches de release, du moment qu’elles ne contiennent que des changements de config YAML, pas les raw spec ou JSON générés, qu’il faudrait alors gitignore.
Mais pour gitignore ces artefacts, il faut aller au bout de la démarche embed qu’a commencée Hugo, en permettant à Duniter de démarrer sans erreur si ces fichiers ne sont pas présents (actuellement, il crash si c’est le cas).
C’est un peu flou de mon côté, et je crois comprendre qu’il y a eu un genre de quiproquo à ce sujet de embed entre vous trois avec @elois, qu’il faudrait démêler.
Pour aller dans ce sens, j’ai ouvert une MR pour la branche network, mais qu’on peut fermer en fonction de la décision.
En gros il n’y a que le gtest-raw.json qu’il faudrait à terme gitignore quand on aura éclairci ces histoires de embed.
On pourra alors en profiter pour nettoyer l’historique git de tout ces fichiers de build.
1 Like
Plutôt network/gtest-1100 j’imagine. #333 pour tracer.
1 Like
Branche network/gtest-1100 mergée : Network GTest runtime 1100 (!348) · Merge requests · nodes / rust / Duniter v2S · GitLab.
Les raw specs ont été sorties du code source à cette occasion.
2 Likes
Chouette, et tu as testé que Duniter démarre bien si jamais ces raw specs ne sont pas présentes localement ?
Non, mais qu’est-ce que signifie “démarre bien” pour toi ? A quelle “gdev” t’attends-tu dans ce cas ?
Bonne question. Je ne sais pas trop, à la chaine locale par défaut, réseau dev alias gdev si j’ai bien compris.
Je ne sais pas du tout si la chaine gdev locale lancé par defaut est associé à un raw spec en particulier, ou si tout est chargé à partir de fichier de config, j’avoue que je ne maitrise pas du tout cette partie, je ne m’y suis pas intéressé.
Mais je sais que @HugoTrentesaux semblait me dire qu’il fallait probablement porter attention à ce point (pouvoir démarrer Duniter sans ces raw spec grace à l’option embed).
1 Like
J’ai retrouvé la réponse de Hugo à cette question. Mais ce n’est pas plus clair, car dans sa réponse il laisse le choix : gdev peut aussi bien être la chaîne dev (montée de toute pièces avec alice, bob et cie) qu’une gdev basée sur la Ğ1.
Mais une monnaie basée sur la Ğ1 implique nécessairement un dump (fichier g1-data.json).
Pour l’instant celui-ci est toujours présent dans les sources, sauf qu’il date de plus d’un an ce qui empêche la chaîne de démarrer, exemple de message :
thread ‘main’ panicked at node/src/chain_spec/gen_genesis_data.rs:987:13:
Pini is an inactive technical commitee member
Parce que les données sont ré-interprétées à l’heure actuelle et que Pini (comme toute autre membre) se fait éjecter immédiatement vu la date d’expiration de son adhésion pour ce dump.
Moralité : le chaîne pourrait démarrer mais il faudrait un dump récent … et alors soit on le met dans les sources (on a dit qu’on ne voulait plus faire cela), soit il doit être tiré ou généré à la volée.
- tiré : on peut prendre celui d’un réseau en cours (il faut chercher …) mais on peut retomber dans le même problème que le fichier g1-data.json déjà embarqué ;
- généré : oblige à tirer le dump quotidien de la Ğ1 présent sur mon serveur, ça crée une dépendance à mon infra, puis ça lance un Docker pour générer le fichier g1-data.json.
Bref dans tous les cas c’est lourd. Mais c’est inhérent au fait de vouloir utiliser les données de la Ğ1.
Ou alors, on veut encore autre chose : par exemple on veut les données de la Ğ1 d’une époque et bosser sur cette base. Le fichier g1-data.json est déjà présent. C’est déjà possible, il faut juste utiliser une variable d’environnement :
DUNITER_GENESIS_TIMESTAMP=1705991033 cargo run -- --chain=gdev
Dans ce cas, peut-être que la chaîne gdev sans embed devrait automatiquement signifier DUNITER_GENESIS_TIMESTAMP=1705991033 pour ne pas avoir à le spécifier ?
Les possibilités sont multiples …
1 Like
Pour moi la chaîne dev par défaut ne doit pas charger les données de la g1. Juste quelques données mockées : quelques identités avec tous les types de statuts et cas de figure envisageables, dérivées d’un même mnemonic, celui de test Substrate, documenté, ainsi que des wallets et identités liés à des clés dérivées au format id/password, documentés aussi, comme j’imagine ce qui est déjà fait pour les tests Cucumber — en tout cas ce qui est fait en partie dans gecko pour les tests d’intégrations, reprenant tous les wallets Alice/bob/etc. plus quelques autres.
2 Likes
Oui, et la chaîne gdev ?
Question à 50 points.
Je pense qu’il faut mocker des données de la g1 à un instant t pour ne pas avoir gérer un truc trop compliqué de synchro dans le temps.
Me semble un bon compromis.
Le seul intéret de pouvoir lancer un gdev local avec les données de la g1 c’est de mocker un max de donnée dans toute sa diversité, issue du monde réelle. Peu importe de quand elles dates.
1 Like
Je vais essayer d’expliquer mon idée de “embed” en revenant aux sources.
// fichier /node/src/command.rs
// génération de chainspecs au lancement du noeud avec des paramètres hardcodés
"dev" => Box::new(chain_spec::gdev::local_testnet_config(1, 5, 6)?),
// génération de chainspecs au lancement, mais avec un fichier yaml lu au lancement du noeud
"gdev_dev" => Box::new(chain_spec::gdev::gdev_development_chain_spec("resources/gdev.yaml".to_string(),)?),
// génération de chainspecs au lancement à partir d'un fichier de client specs et de conf lu au démarrage
"gdev_live" => {
const CLIENT_SPEC: &str = "./node/specs/gdev_client-specs.yaml";
let client_spec: chain_spec::gdev::ClientSpec = serde_yaml::from_slice(
&std::fs::read(
std::env::var("DUNITER_CLIENT_SPEC")
.unwrap_or_else(|_| CLIENT_SPEC.to_string()),
)
.map_err(|e| format!("failed to read {CLIENT_SPEC} {e}"))?[..],
)
.map_err(|e| format!("failed to parse {e}"))?;
Box::new(chain_spec::gdev::gen_live_conf(
client_spec,
"resources/gdev.yaml".to_string(),
)?)
}
// embed de chainspecs au format raw.json avec include_bytes
"gdev" => Box::new(chain_spec::gdev::ChainSpec::from_json_bytes(&include_bytes!("../specs/gdev-raw.json")[..],)?),
Le seul truc qui me pose problème, c’est de commiter le ficher raw qui est inclus comme un blob dans le binaire par le macro include_bytes. Donc :
Non, pas de raw spec pour cette chaîne dont les specs sont générées.
Ça dépend le fichier de config qu’on vient lire.
gdev_client-specs.yaml: uniquement engdev_livegdev.yaml: à la fois engdev_liveetgdev_dev, mais pas endev
Well, what would mean
gdevfeature in terms of specs if it’s not to use the raw specs file?
That would mean to have only a local testnet as generated by
chain_spec::gdev::local_testnet_config()or to launch from yaml + json file as inchain_spec::gdev::gdev_development_chain_spec(). No data embeded. No “default network” embedding needed.embedfeature would only be enabled in network branches and would only build in network branches. That would allow the absence of raw chainspecs file inmasterbranch which is what I am looking for actually ^^
La feature gdev est une feature de compilation qui donne accès à plusieurs commandes de chaine (--chain=xxx). Générée de tout pièces (dev), générée à partir de gdev.yaml (gdev_dev), ou générée à partir de gdev.yaml et gdev_client_specs.yaml.
La feature “embed” s’ajoute à une feature gdev ou gtest pour inclure des raw specs dans le binaire à l’aide de la macro include_bytes!.
En effet. Et l’idée du include_bytes est de permettre une répétabilité parfaite, quel que soit le timestamp actuel. La génération dynamique peut se faire comme tu dis, mais il me paraît normal de devoir donner en paramètre le timestamp auquel on souhaite jouer les tests de cohérence du genesis.
Oui, je suis d’accord.
La chaîne gdev à mon avis devrait n’être disponible qu’avec un embed des raw specs. Si on veut changer quoi que ce soit, c’est donc une autre chaîne, donc gdev_dev ou gdev_live en fonction de ce qu’on veut changer.
Effectivement je confonds et navigue implicitement entre les notions de feature et de chaîne.
On va supposer ici que la feature gdev est activée.
Pour reformuler, ce qui serait souhaité/souhaitable sous cette hypothèse :
- que la chaîne
gdevne soit disponible que dans les releases du client pour la ĞDev (donc, avec featureembedoù les raw-specs sont celles générées officiellement dans le cadre d’une release) - le reste du temps (hors release, où la feature
embedest supposée désactivée) les seules chaînes liées à la ĞDev seraient :gdev_dev: se base surgdev.yamlet attend le fichierg1-data.json, permet de tester/développer en local avec des données de la Ğ1 mais avec Alice comme seule autorité ;gdev_live: même idée sauf que cette fois les autorités sont celles définies pargdev.yaml. Le but est ici de pouvoir lancer une ĞDev rapidement (sans attendre la livraison des clients Docker et cie).