Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Bifrost to modify Logs in case of missing Chains #1342

Closed
wants to merge 15 commits into from

Conversation

tillrohrmann
Copy link
Contributor

This commit allows Bifrost to update the Logs configuration
in case a missing Chain for a given LogId is detected. In this
case, the Bifrost client tries to update the Logs configuration
with its configured default provider.

This fixes #1341.

This PR is based on #1338.

@AhmedSoliman let me know if this commit goes against the ideas you had for Bifrost.

Let Bifrost obtain the number of partitions from the available
partition table.
The PartitionProcessorManager is responsible for managing the lifecycle
of PartitionProcessors. The set of partition processors can be modified
by providing a PartitionProcessorPlan that contains actions how to change
the running set of PartitionProcessors. At the moment only starting
partition processors is supported.
This commit changes the APIs for obtaining the PartitionTable metadata
to optional to underline the contract that a PartitionTable might not
be loaded.
This commits moves the ground truth of th logs
configuration to the metadata store from where
it is also retrieved at start-up of Bifrost.

This fixes restatedev#1336.
This commit allows Bifrost to update the Logs configuration
in case a missing Chain for a given LogId is detected. In this
case, the Bifrost client tries to update the Logs configuration
with its configured default provider.

This fixes restatedev#1341.
@AhmedSoliman
Copy link
Contributor

I'm not sure we should auto provision log-ids implicitly on appends. Provisioning logs should happen only during partition split or merge. I can think of many risks to this approach, too many to enumerate actually :D

@tillrohrmann
Copy link
Contributor Author

Fair point.

What's currently not very intuitive is that the default_provider in Bifrost's options is not respected when explicitly creating a Bifrost service in tests when using the TestCoreEnv because TestCoreEnv initializes the Logs based on the PartitionTable (similar to what the node does on normal startup). One simple solution could then be to make the ProviderKind configurable when creating the TestCoreEnv.

@AhmedSoliman
Copy link
Contributor

Should we close this one then?

@tillrohrmann
Copy link
Contributor Author

Jup. Closing as too dangerous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow Bifrost to run w/o statically configured metadata in tests
2 participants