#Fork guide feedback
1 messages ยท Page 1 of 1 (latest)
Steps 1, 2, 3, 4 should be more explicit or with examples.
- What is "root directory of Namada", given that we've just zipped the
.local/share/namada/shielded-expedition.88f17d1d14? - Should we
cdin namada project that we cloned to build from source ? - Where do we find
.wasmandchecksums.json? - Why "the team encourages operators to try to produce the file themselves" if they provide a DL link ? why take the risk of messing things ?
Sorry to be picky, but that's the kind of thing I really dont want to get wrong ๐
Thanks for sharing in advance, it's good to be able to have a view of what's coming
"namadan-0.32.0: the new runtime to which we are upgrading from the v0.32.0 release." - this doesn't make sense
why is namadan and not namada used consistently throughout the guide?
building from source which is a crucial step in the procedure is not possible for many users, as the build is quite ram-intensive and tends to fail < 24GB ram
build process from specific branch would need elaboration for many users I think
I don't understand why you don't just provide a binary from this branch? there doesn't seem to be any reason as best I can tell to build from source
agree with phychain on the migrations-json. think it will overcomplicate things
there could be a little more clarity and precision around the different binaries/builds, in particular it's unclear how namada we build (migration branch) and namadan-mig (supplied binary) interacts. I mean I get it, but think that's overcomplicating things tbh.
ok that's it from me
oh also, how will the indexer behave wrt hard fork
@bold widget fyi โ๏ธ
Agree.. also as Pretoro we wannna able to download binary file directly instead of manual build it.
Fork guide feedback
hi guys! thx for the feedback so far. I'll try to answer some questions here and then update the instructions appropriately. Also, feel free to use the open PR to submit feedback as well. Happy to look in this thread still for questions too though
@warped gale Answers:
- The "root directory of namada" refers to the top level directory of the namada repo that you can clone from github: https://github.com/anoma/namada.
- Yes, typically one would do something like
git clone git@github.com:anoma/namada.git && cd namadaand you would then be in the root directory and run commands from here after building. - The last line of
Hosted files and materialsmentions where the wasms will eventually be provided. - We encourage operators to try to produce the file themselves as a good exercise of something that could be very helpful to do during mainnet if needed. We should all be striving to be optimally capable with the software and procedures for when mainnet comes, and the SE is a great opportunity to experiment. The rist of messing things up is mitigated by the files that we will host. As described in the docs, you can
shasum migrations.jsonand compare the output hash against the one we publish. If for some reason you are unable to produce the same exact one, then you can just download the file. If you are, then you've learned a valuable skill. Perhaps @stark owl can comment more on this too.
@late mortar Answers:
- yeah sounds a bit confusing, changing to "the new runtime from v0.32.0"
namadanis used throughout the guide because this is the exact binary to run. It is the same as doingnamada node. I'll specify that the two are interchangeable.- I think this would be good for operators to be able to do. For the record, my work laptop has 16GB of RAM and I am able to build Namada wihtout any problems.
make build-releasetakes ~10 min from what I recall. You can also do these steps (though I may have to include extra instructions) by building namada on your local or other machine (it does not have to be the same machine you run your node on). However, we are trying to provide a way around this soon, and maybe you won't need to build from source, but truthfully this might require to push the hard fork by an extra day or something to include it. - Ok, I can provide extra steps for that. Thx
- We can provide at least some of the binaries we are asking you to build. but we probably can only do it for linux machines and not Windows or x86_64. I didn't think building from source would be that much of a concern, but it is possible I've misevaluated.
- Can you elaborate more on how the description of the different binaries/builds might be lacking? Thx, I know it does look complicatedm, but I'm trying to be as precise as possible. Hopefully we might be able to simplify the instructions soon.
@late mortar I'm not sure about indexer but will try to find out for you
maybe it makes sense to add some of the additional context to the instructions? without overdoing it
Cheers @bold widget thanks for clarifying everything, looks good to me.
I'll be glad to try to build it, I have the CPU/ram for it
Btw, I just updated the instructions again, there is a new release v0.32.1 that removes the need to have separate namada-0.32.0 and namada-0.32.0-MIG binaries (now combined into one)
awesome!
i specified v0.32.0 and its commit hash in the governance proposal, but i imagine that v0.32.1 and v0.32.0 are compatible
is it possible to create an executable binary from this command cargo run --example make-db-migration ?
I'm using docker and i can build images myself but since we don't have Cargo in the final stage image, it would be much easier to build this command in the build stage and then just copy the binary to the final image
@bold widget
@stark owl do you know if we are good or not on the proposal for the hard fork? I see rejected on extended Nebb but ok on namascan. I'm at a loss. (I'm not on my PC, I can't check the tally on command line)
It's the last epoch for voting, and I think we are still missing a couple % to reach turnout/quorum. Can we have an announcement so that everyone votes YAY ?
There are a ton of Abstain and Nay votes, this is a nonsense/unacceptable for the advancement of the SE. Do we have Shielded-100 validators voting Nay or Abstain ?
yeah @warped gale it failed: https://explorer.node75.org/namada/proposals/385
i think we should still push onward, even tho it failed to meet quorum
obviously this should never happen on mainnet, but yeah, it's time to move forward, haha
What steps can I try to finish before the hardfork block. As I see from the guide, 1) stopping and starting node to halt at block xxx is something we can do now. Anything else I can do before the actual hardfork? Also @stark owl just want to confirm can I switch of and start the node to halt at the block 229614 or should we wait as this block for halting/hardfork initiation might change?
Building from source has been tricky for me in the past, hence if a binary is available for steps after node is halted I would prefer that.
Linux build would work for most users I think
As far as a higher level summary of the process goes I see three main steps :
- Configure to halt your node at block 229614 using the current binary 0.31.9.
- Generate migration.json using binary 0.31.9-MIG
- Restart node and update DB using binary 0.32.1 binary, the node will progress 2 blocks and halt, and will need to be started again. Does this sound good as a higher level summary of steps?
think there's a bit more but haven't looked at last draft. will look tmw
For me, it is not clear when to upgrade v0.32.1
my brain helted thanks to namada.
reading through again.
bit of semantic confusion on my part, what's the relation between namadan / namada node and namadan ledger / namada ledger?
there is still some confusion/bad congruency for me, when it comes to talk of providing binaries in the introduction and then later instructions to build source. I don't mind building the source myself, but I think it will be a stumbling point for a lot of the participants here and then potentially for the migration wholesale. (also, re the specs/hardware issue, I had to upgrade to minimum 24GB ram to compile. 16GB left me with halt on vps).
imo better to mark the production of this file as clearly optional for clarity, but idk. just my thoughts.
also, I wonder what the incentives will be like operationally. if I understand it correctly, we all halt at a given height, and then we do "the steps". if the goal is to get one's validator up and running asap, there will be a greater incentive to skip the more complicated step of this and just use binaries/provided migrations file - possibly having the ones that take more time on the former be jailed while chain moves on? or will there be some planned downtime before shielded-100 hooks up their voting power?