gnolang
feedback needed: how are you using `gnoland genesis ...`?
I'm considering whether these commands should be included in the gnoland binary, placed elsewhere, or if they are necessary at all.
I would appreciate feedback on how people are currently using these commands. If no one is using them yet, please explain how you envision using them in the future.
Additionally, if you're already using them and have suggestions for improvement, please share your thoughts.
Not much; but I personally haven't operated a node. I did find the secrets and config commands useful in my debugging and suage though.
I see a point in having commands to manipulate genesis files as compared to using genesis_txs and genesis_balances, which then get combined into a genesis file. These are not removed yet, but they should be. I wonder whether there should be some shared functionality, like the one that gnoland start --lazy uses, that can be shared; while keeping most of the genesis command in a contribs/ binary, like gnogenesis.
I doubt many, even among node operators, will need to use the genesis commands. Even #2841 is a glorified wget + sha256sum.
@zivkovicmilos wdyt?
@moul
I'll give my feedback here since I mostly designed the current genesis command suite
I'm starting from the premise that a node operator does not need to be aware of different tools (binaries) in order to boostrap their blockchain deployment. It's pretty standard across the ecosystem to bundle chain building tools into the blockchain client binary, and release them with the binary (there are no 2 release streams for the client and helpers like these, but a single one, that always works).
The historical reason why it's bundled is because it makes the lives of our DevOps friends x10 easier, when they need to fetch a single binary and orchestrate everything from it -- this binary is not used for a single step, but across workflows that can be as complex or as easy as you like.
I do agree @moul that the CLI suite we have is a bit bloated, even though it's extremely useful (if we're looking for a CLI suite to tackle with the most impact on sanity, please see gnokey). I personally am very happy with the chain orchestration flow we have now in comparison with the past, and in comparison to what's standard in Cosmos today. There are a few legacy patches here and there that I'd love to remove (the files Morgan is mentioning are prime examples), we have some issues already opened.
If the idea is to make the gnoland binary slim, I think there are better ways to tackle it than leaving a single start command (the insane parts of the codebase that gets compiled, but never used).
Removing genesis, will trigger a question if secrets and config also require their own binaries (so we'd need to install 4! tools to orchestrate and manage a chain. That would be a fun tutorial to read and follow 😃)
@thehowl
I doubt many, even among node operators, will need to use the genesis commands
This is not really true, I invite the ops family (@sw360cab, @albttx, @mazzy89, @r3v4s, @D4ryl00 and others) to give their opinion on this discussion as well :)
IMO it is useful to keep genesis subcommand, it provides a set of functionality that can be really handy from a devops POV. It allowed me to perform multiple actions related to genesis file without the need of any extra command or tool. This means I could use gnoland as base image that in turn is not requiring any extra tool in already installed in it.
Probably in a testnet or mainnet scenario this is not the case. But when dealing with dev or staged environments that can be bootstrap from scratch, I found the command handy and useful.
@sw360cab That makes two of us.
Once we launch mainnet and after it gets stabilized, no need to do something with genesis. But for staging, it is very handy to keep it.
Does anyone have a good reason not to move it to contribs/gnogenesis?
Else, we should do it asap, please.
Does anyone have a good reason not to move it to
contribs/gnogenesis?
After discussing with Sergio, I'm a bit more convinced that they make sense to be kept in the gnoland command. It means that the gnoland command can manage the entirety of its related files without any additional tooling. It is useful to work in staging environments; so I no longer see particular harm in keeping it.
That said, we could take 5 minutes at the retreat to come to a conclusion :)
Does anyone have a good reason not to move it to contribs/gnogenesis?
this, please.
@moul can you state your case for moving them instead?
especially since we have secrets and config already in gnoland. why do you need to install 2 different binaries for managing a node and its genesis, especially as we are establishing that gnoland is primarily for node operators (and gnodev for individual users)? why do you need it to split it out from secrets and config?
okay, node operators on mainnet won't need it, but there'll still be testnets managed by us and partners, even after mainnet.
gnoland is used to manage a node.
gnogenesis is for managing a genesis, which is a different process. A node operator should only manage a node, not a genesis.
For testnets, the situation is similar; someone will create a genesis so that node operators can simply use gnoland.