[chain] Remove lazy chain initialization for gnoland start
#1886
Labels
📦 ⛰️ gno.land
Issues or PRs gno.land package related
Milestone
Comments
7 tasks
|
I request a discussion before removing lazy initialization from the start of Gnoland. |
|
@moul we discussed in the review meeting and we're pretty much in agreement on removing the lazy initialization :) though I'll keep this in the review meeting column so we can hear your arguments. |
3 tasks
|
Let's discuss, yes. Before that, I need to review the usage documentation in the other PR from Milos that I requested. |
zivkovicmilos
modified the milestones:
🏗4️⃣ test4.gno.land,
🏗4️⃣ test4.gno.land [POST LAUNCH]
zivkovicmilos
added a commit
that referenced
this issue
May 26, 2024
## Description This PR started as an implementation of the `gnoland init` command, that initializes the node configuration and secrets, as part of #1885. However, throughout the lifetime of this PR, discussions with @moul have shaped the PR to take a different approach: - `gnoland init`, because it's an alias, does not warrant its own subcommand (it's a combo of `gnoland config init` and `gnoland secrets init` - `gnoland start` should have a much more clear lazy init flow, and it should be **optional** (I added this with the `--lazy` flag). Here is an example of the flow: - <img width="1262" alt="Screenshot 2024-05-14 at 14 42 15" src="https://github.com/gnolang/gno/assets/16712663/30fe0f0a-0078-47af-802a-7cc6909aa3ee"> - documentation that was initially done for `gnoland init` is adapted to use the `gnoland config` and the `gnoland secrets` command suites (this was easy to do, they are an alias) - Lazy initialized secrets and files now show up with a **WARN** label in the CLI - I've updated the init logic for secrets, so that it supports partial initialization, since the original `gnoland start` lazy init regenerated everything that was missing and skipped everything that was present. Partial initialization means that missing secrets are regenerated, and existing ones are skipped - I've dropped a few useless flags for `gnoland start`, with more to be pruned in future PRs. These were legacy / leftover, as we've added better support for them in the meantime As a consequence of these discussions, we have decided to table lazy init removal for the future -- #1886 Closes #1885 Thank you @albttx, @r3v4s, and the team for discussions that led us to finalize this bigger effort of node init flows 🙏 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Master issue: #1836
This issue concerns removing lazy node init logic from
gnoland start, as the node / chain initialization flow is specifically defined in #1836.Blocked by:
genesis.jsonpath flag tognoland start#1883config.toml#1884gnoland initcommand #1885The text was updated successfully, but these errors were encountered: