[R-W Bridge] Redeploy to start relaying/synching

[EmmanuellNorbertTulbure]

• add version guards to RBH<>WBH GRANDPA finality
  added version guards to RBH<>WBH GRANDPA finality (and complex) relay #1697
• update relayer to complex one:
  https://gitlab.parity.io/parity/infrastructure/parity-testnet/-/blob/master/parity-bridge-common/wococo-relay-header.yaml#L4
  https://gitlab.parity.io/parity/infrastructure/parity-testnet/-/blob/master/parity-bridge-common/rococo-relay-header.yaml#L4
• set fixed defined RuntimeVersion for RBH and WBH
  Set R/WococoBridgeHub bundle runtime version #1756

[bkontur]

@serban300
you could also take this one, now there is no version guard for Ro/Wo,
we are waiting for deployment of bridge-hub-rococo-9302 https://github.com/paritytech/devops/issues/1934#issuecomment-1375554017

so I would like to setup bridge-hub-rococo-9302 as starting version guard for Ro/Wo,
it is not really needed for testnet, but I would like to set it up to be as-close-as-possible to the later Kusama/Polkadot bridge - just to avoid any unexpected surprieses in production :)

[serban300]

Thanks ! I'll assign it to me then and I think I'll be able to do it these days.

[bkontur]

@svyatonik
Slava, do we have/need something for monitoring/alerts about "version guard"?

[svyatonik]

Version guard isn't about monitoring - it is about stopping the process when the relay detects it is connected to node that is using unexpected version. E.g. in Kusama<>Polkadot bridge when one of chains is upgraded, the relay stops (because of version guard) and we shall check that the upgrade isn't breaking our bridge and then we have following options:

• just recompile relay with upgraded bundled chain version and restart it;
• wait until the other chain is upgraded (e.g. we may need to wait for Kusama upgrade if Polkadot has been upgraded) - during that time, we shall not start relay;
• do some coding, republish and restart relay;
• something else that I can't think of now.

In any way - let me prepare some doc (before Thursday) - we need to discuss how we'll be handling runtime upgrades (have some process, some tools, ...). Maybe we can optimize/reduce number of manual actions. Let's discuss it on Thursday.

[bkontur]

yes, yes, ok, cool,
I was thinking more about, how do we receive information that relayer was stopped by guard? Do we receive some notification on matrix or how?

[svyatonik]

yes, yes, ok, cool, I was thinking more about, how do we receive information that relayer was stopped by guard? Do we receive some notification on matrix or how?

Most of dashboards will switch to NoData state and we'll get alerts (unless relay is configured to be autorestarted by devops - needs to be checked) -> alerts will go to the matrix room. But the problem is that we'll be getting alerts until we'll get the relay restarted, so ideally we'll start preparing new relay version when we have a release draft and will be ready to restart asap after upgrade. But again - let's discuss it on Thu - maybe we'll come with some better solution.

[svyatonik]

One of possible solutions that I'm currently leaning towards (to decrease our maintenance burden) is to halt on transaction-version change instead of spec-version change. We now don't care about message payload to be delivered before upgrade (vs our previous encoded-call messaging) => probably it'll be better. But we need to discuss that first

[serban300]

Set the bundle runtime version to {spec_version: 9302, transaction_version: 1} for R/Wococo bridge hubs .

@bkontur @svyatonik do you want to address the upgrade process as part of this issue, or do we need to do anything else here ?