#Fork guide feedback

1 messages ยท Page 1 of 1 (latest)

warped gale
#

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 cd in namada project that we cloned to build from source ?
  • Where do we find .wasm and checksums.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

late mortar
#

"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

late mortar
#

oh also, how will the indexer behave wrt hard fork

stark owl
#

@bold widget fyi โ˜๏ธ

short escarp
stark owl
#

Fork guide feedback

bold widget
#

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 namada and you would then be in the root directory and run commands from here after building.
  • The last line of Hosted files and materials mentions 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.json and 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"
  • namadan is used throughout the guide because this is the exact binary to run. It is the same as doing namada 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-release takes ~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

stark owl
warped gale
#

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

bold widget
#

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)

stark owl
runic turtle
#

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

warped gale
#

@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)

warped gale
#

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 ?

stark owl
elfin fog
#

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.

elfin fog
#

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?
late mortar
red sphinx
jagged mortar
#

my brain helted thanks to namada.

late mortar
#

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?