[Merged by Bors] - Don't rewrite poet config

[poszu]

Motivation

The poet config is unnecessarily and wrongly rewritten in node setup code.

Changes

Don't rewrite poet config at all.

[codecov]

Codecov Report

Merging #4782 (772c0fc) into develop (2c512aa) will increase coverage by 0.0%.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##           develop   #4782   +/-   ##
=======================================
  Coverage     76.7%   76.8%           
=======================================
  Files          260     260           
  Lines        29524   29522    -2     
=======================================
+ Hits         22672   22680    +8     
+ Misses        5407    5399    -8     
+ Partials      1445    1443    -2     

Files Changed	Coverage Δ
activation/poet.go	75.6% <100.0%> (+0.4%)	⬆️
node/node.go	65.3% <100.0%> (-0.2%)	⬇️

... and 4 files with indirect coverage changes

[dshulyak]

would it be nice to have a test that correct config is being used? also true for other components obviously

[poszu]

would it be nice to have a test that correct config is being used? also true for other components obviously

Yes, but engineering a systest to check it would be really painful. Would you happen to have an idea of how to test it best?

[dshulyak]

maybe just a unit test to check that correct config is being used in poet client.
or systest, that ensures that we always select best poet proof even if it becomes available later, thinking:

• throttle one of the poets with lower cpu limits - slow poet
• make poet round end later (by 10s for example) on the fast poet
• assert that all atxs are using fast poet

but it is indeed time consuming to setup all that

[poszu]

* throttle one of the poets with lower cpu limits - slow poet

* make poet round end later (by 10s for example) on the fast poet

Actually there is no need to throttle if one of the poets runs for less time, because then it will have less ticks.

[dshulyak]

Actually there is no need to throttle if one of the poets runs for less time, because then it will have less ticks.

true, but i assumed that 10s will not necessarily guarantee more ticks

[poszu]

bors merge

[bors]

Pull request successfully merged into develop.

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• ci-status
• systest-status