Rococo onboarding improved flow

[nuke-web3]

Is there an existing issue?

• [X] I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• [X] This is not a support question.

Content request

Rococo teams need to know a bit more explicitly perhaps that when going to register they must:

• use the correct chain specification file from the Polkadot repo and check that it matches the live network in production (around rococo resets this is critical)
• edit their chain specification for the collators such that they have:
  • boot nodes for their network
  • session keys configured that are not well known
  • more customized per their lover term testing needs, perhaps more prefunded accounts that are not the dev well known ones too.
• a Polkadot js PR in draft with all relevant chain info ready to go before launching
• a press release if they want to issue one after they confirm they are live and producing blocks.

Suggesting that all teams attempt one trivial runtime upgrade using the how to guide before anything else, to ensure they understand the flow (after testing locally!)

Are you willing to help with this request?

Yes!

[bernardoaraujor]

InvArch Rococo post mortem

InvArc started their parachain onboarding routine, but at some point they got confused and missed their announced launch date.

they upgraded into a parachain status, but wouldn't produce blocks, with the following error message:

2022-03-24 23:50:41 [Parachain] Could not find the header of the genesis block in the database! block_hash=0x9221c0434e794cb12eea8c8040d026e8264286dccd4041c2170a13f3f876bf67

first suspect was conflicting genesis state, so we sudo forced a new geness state

then, collator would show:

2022-03-25 11:57:06 [Parachain] Starting collation. relay_parent=0xc0051549ff9fbaf3e6222773af289d579b1fc5eaf4f1c7bb0e4ad127dc13810f at=0x8b3f8de69906dac8a6b7427526cc38ae277354101192ab82ba95c900aa9f68dc
2022-03-25 11:57:08 [Parachain] 💤 Idle (2 peers), best: #0 (0x8b3f…68dc), finalized #0 (0x8b3f…68dc), ⬇ 0 ⬆ 0
2022-03-25 11:57:08 [Relaychain] 💤 Idle (28 peers), best: #154584 (0xc005…810f), finalized #154581 (0x9618…a211), ⬇ 34.3kiB/s ⬆ 29.8kiB/s

their chain still wouldn't produce blocks.

there was some brief investigations about session keys, bootnodes, chainspec.

• session keys were submitted via author.insertKey
• bootnode was taken from the full node instance that is also running in onfinality, and we suggested these:

  [
  /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWBkb8ZBVne6f1v65ShcUNbSh9V6bDQnvJHAjmrB5xUQVq
  /ip4/10.14.0.124/tcp/30333/p2p/12D3KooWBkb8ZBVne6f1v65ShcUNbSh9V6bDQnvJHAjmrB5xUQVq
  ]

iit was noted that their local collator (not on OnFinality) didn't have parachain peers

since they were trying to meet deadlines, it was suggested that we get a new paraId, use default keys and start from a blank stot. things seem to be going smooth since then.

their words on the incident:

I think the tutorial misses the transition of the chainspec from local to live chain, I also found a lot of useful information on aura keys in the private chain tutorial that might make sense to add to the cumulus one. But that's the main thing I think is missing, the tutorial goes from having a local parachain chainspec to having you register the state and wasm on the live chain without much information on what should change from the spec, ie: it goes from using --alice to going live without explaining how to do what --alice does but with your own keys