Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

service: use deny-list instead of allow-list for BEEFY #5331

Merged
merged 7 commits into from Apr 26, 2022
Merged

service: use deny-list instead of allow-list for BEEFY #5331

merged 7 commits into from Apr 26, 2022

Conversation

acatangiu
Copy link
Contributor

@acatangiu acatangiu commented Apr 15, 2022

Instead of allowing BEEFY to run on specific test nets, reverse the condition to explicitly disallow BEEFY on production chains that we don't want it to run on yet.

This allows other test chains (Rialto used in bridges) to use the polkadot service file and still be able to run and test BEEFY.

Needed for paritytech/parity-bridges-common#1286

Release Notes

--beefy CLI option is now explicitly disallowed on polkadot, kusama and westend chains, and will error out.

@acatangiu acatangiu added A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit. labels Apr 15, 2022
@acatangiu acatangiu self-assigned this Apr 15, 2022
Copy link
Contributor

@svyatonik svyatonik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There must be some story behind this code - I haven't seen the PR where it has been introduced. But I wonder if we may change behavior a bit - instead of silently ignoring cli option (I guess enable_beefy flag value comes from cli, right?) can we return Err(_) from new_full when someone is trying to enable BEEFY on Kusama/Polkadot/Westend? Otherwise it seems strange to see node is successfully starting, but BEEFY is not running :) Or it may break some deployments - i.e. is BEEFY cli flag enabled by default?

@acatangiu
Copy link
Contributor Author

There must be some story behind this code

Unfortunately, I don't know the story of this code and why original decision to override CLI and silently disable (as opposed to explicitly disallow and throw error) BEEFY was made...

Now we can either keep that behavior, or as you say return Err(_) from new_full() and fail to start nodes for production chains when BEEFY enabled thru CLI param.

While I agree the latter is cleaner, more clear and explicit, this PR implements the former because I'm not sure about the impact it would otherwise have on deployments. Went the safe route to avoid breakages.

Another supportive argument for keeping current behavior is that it is temporary, with plans to have BEEFY running on all chain specs by end of this year.

@acatangiu
Copy link
Contributor Author

I need a @paritytech/core-devs reviewer here, please

node/service/src/lib.rs Outdated Show resolved Hide resolved
config.chain_spec.is_kusama() ||
config.chain_spec.is_westend()
{
enable_beefy = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a warn: if enable_beefy { warn!("Tried to enable BEEFY on a production network. Refusing as BEEFY is still experimental.") }. Something along those lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that as well, but I found it odd that log crate is not used anywhere in node/service and I just assumed there's a reason for it...

I'll add log dependency and log a warn!, but writing it out here as well so anybody who knows of a reason we shouldn't, can react 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a local crate for logging that also deals with tracing gum::warn! should work.

Copy link
Contributor

@drahnr drahnr Apr 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still need to make that easier to discover, but here's the rationale for the interested reader around why we need gum https://github.com/paritytech/polkadot/blob/6cafab2d926000fa612af29b02e8ed482d4dd9c5/node/gum/README.md

Copy link
Contributor

@cheme cheme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code change looks good to me.
Yet if it matters that we don't have it running for polkadot and kusama. It may matter to other chain, so I would maybe switch to B1-releasenote.
(other node can always override the cli value in their bin crate).
Edit: thinking twice, this comment only really make sense if it was in substrate so please ignore.

@acatangiu acatangiu added B1-releasenotes and removed B0-silent Changes should not be mentioned in any release notes labels Apr 19, 2022
@drahnr
Copy link
Contributor

drahnr commented Apr 19, 2022

We had troubles when first enabled by default, mostly performance related iirc, but that has been a while (1a+) ago.

Complexity of new_full and it's inner helpers is already too high ( paritytech/polkadot-sdk#939 ), could we not resolve this at the arg preparation (before entering new_full) level?

node/service/Cargo.toml Outdated Show resolved Hide resolved
Instead of allowing BEEFY to run on specific test nets,
inverse the condition to explicitly disallow BEEFY on
production chains that we don't want it to run on yet.

This allows other test chains (other than Rococo/Wococo)
that use the polkadot service file to enable and test BEEFY.

Signed-off-by: Adrian Catangiu <adrian@parity.io>
Copy link
Contributor

@drahnr drahnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good, imho this is breaking the public contract, so it should be part of the changelog since manual intervention is required to maintain the previous behavior.

How does this play out at the perf side? Do we expect any impact for the regular validator execution paths?

@acatangiu
Copy link
Contributor Author

it should be part of the changelog since manual intervention is required to maintain the previous behavior.

Is there anything else to do other than set B1-releasenotes label to get it in the changelog?

How does this play out at the perf side? Do we expect any impact for the regular validator execution paths?

No, we do not expect any performance impact even when BEEFY is enabled. BEEFY gadget is driven by finality notifications and other validators' gossip of votes also driven by their finality notifications, so overall little traffic.

@acatangiu
Copy link
Contributor Author

Complexity of new_full and it's inner helpers is already too high ( paritytech/polkadot-sdk#939 ), could we not resolve this at the arg preparation (before entering new_full) level?

The potential for code reuse of the polkadot_service::new_full() fn in other chains, and its high complexity are sort of the two sides of the same proverbial coin.. I expect new_full() to be externally re-used more frequently than arg preparation or even build_full() (caller of new_full()).

In bridges, in particular, we'd need the changes from this PR in new_full(): https://github.com/paritytech/parity-bridges-common/blob/master/bin/rialto/node/src/command.rs#L197

node/service/src/lib.rs Outdated Show resolved Hide resolved
@acatangiu acatangiu requested a review from drahnr April 22, 2022 10:00
Copy link
Contributor

@drahnr drahnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! LGTM

Signed-off-by: acatangiu <adrian@parity.io>
@acatangiu
Copy link
Contributor Author

bot merge

@paritytech-processbot paritytech-processbot bot merged commit b1da1e2 into paritytech:master Apr 26, 2022
acatangiu added a commit that referenced this pull request Apr 28, 2022
* use deny-list instead of allow-list for BEEFY

Instead of allowing BEEFY to run on specific test nets,
inverse the condition to explicitly disallow BEEFY on
production chains that we don't want it to run on yet.

This allows other test chains (other than Rococo/Wococo)
that use the polkadot service file to enable and test BEEFY.

Signed-off-by: Adrian Catangiu <adrian@parity.io>

* address review comments

* throw error if BEEFY enabled on production networks

Signed-off-by: acatangiu <adrian@parity.io>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants