Look-ahead collator: build on all assigned cores

[sandreim]

#3795 introduces some changes that allow the look ahead collator to specify which core a collation should be backed on. We need to implement something similar to what that PR does for the test collators which use collation pull via collator_fn.

[bkchr]

The lookahead collator is going out of service, quite soon. I don't think we should invest anymore time to fix it.

[sandreim]

I agree with you, but would love to hear some deadline on when #3168 is implemented such that lookahead collator is not needed anymore. Also this is a breaking change and I would expect people still be using it for a while before they invest to swtich.

[bkchr]

Also this is a breaking change and I would expect people still be using it for a while before they invest to swtich.

No one is currently using the lookahead collator. So you can bring the argument for switching to it as well ;)

@skunert already told you that he can deliver a first version that supports multiple cores this week or the next week.

[skunert]

IMO it is fine to implement something for the lookahead collator if you want to get something running quickly for testing. However, integration will be non-optimal, since the lookahead collator only knows about relay triggered block production. If you just want to produce more blocks and submit them, that is not hard to integrate. They will be build directly in succession if you we do not build any kind of slot logic into it. Which brings us to #3168 .

As far as breakage goes, the way we author the blocks themselves does not change. So if you have a chain that has 6s slot time, I think we can make the slot-based authoring compatible.

As for ETA, AFAIR we aligned on April in the last sync meeting, but I think some initial version can come sooner, as I wrote in element.

[sandreim]

Also this is a breaking change and I would expect people still be using it for a while before they invest to swtich.

No one is currently using the lookahead collator. So you can bring the argument for switching to it as well ;)

IIRC we are using it for our system parachains and people are supposed to use it for async backing which is something we are enabling on Kusuma/Polkadot right after the runtime upgrade.

[bkchr]

"Supposed to use" and what people are doing are two different things ;) Also they are not required, because block production will continue to work as before.