Closed abhijeet219 closed 3 months ago
@abhijeet219 Also update the pr message:
drenv fetch ...
run will make this much more clear, since we measure only the time to get fetch the resources, and it is also logged in detail if using -v.Tested using #1359
@abhijeet219 Also update the pr message:
- Reference to Configure rbd-mirror debug logs dynamically #1346 is not relevant now
- When you show running the adding with and without caching, it is not clear if the addon was run on a started environment, and most of the time is spent on fetching the resources. Please make it more clear what is tested.
- Showing only
drenv fetch ...
run will make this much more clear, since we measure only the time to get fetch the resources, and it is also logged in detail if using -v.
Added and explained drenv fetch ...
in the PR message
Should I remove the starting an addon part from the PR message, it is also making the PR message look very long.
Added and explained
drenv fetch ...
in the PR message Should I remove the starting an addon part from the PR message, it is also making the PR message look very long.
@abhijeet219 yes, the current example are long and not clear and better remove. Describing how fetch works is not needed in this PR - it was needed only in the PR introducing the cache.
Currently the addons fetch kustomization resources whenever they are started. This change will start using cache for those resources, so starting an addon can directly use the cached resources.
Changes:
Example demonstrating how the cache works:
Fetching of resources for envs/regional-dr.yaml:
Fetching resources may take different amount of time for different runs. And once fetched, addons can directly use these resources to get started, saving time and escaping the flaky network situation.