[da-vinci] Apply Da Vinci record transformer config to associated store only #1393
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[da-vinci] Apply Da Vinci record transformer config to associated store only
Current code will set DVRT function to ingestion service, and all the store ingestion tasks will share the same DVRT function.
This is not correct if we are running multiple stores with some being DVRT Da Vinci client and some are normal clients.
This PR changes the assumption, and will register the function when a store client is being started.
Also, to support DVRT, we should disable automatic subscription to existing on disk resources during bootstrap stage, as it does not contain DVRT function information. We should rely on user's explicit initialization call to setup function mapping correctly during restart. This PR introduces a method to disable this auto-subscription behavior: "davinci.subscribe.resources.during.bootstrap.enabled", but the default is true, as it is the existing behavior. We will explicitly turn it off when we are spinning up DVRT Da Vinci client.
How was this PR tested?
Adjust integration test and add a new normal client to spin up along with DVRT client and verify the behavior is expected.
Does this PR introduce any user-facing changes?