Speed up SSVM startup time by postponing checks

[ravening]

Description

Currently SSVM takes long time to startup.
Reduce the startup time by moving volume/template
check to post connect TimerTask to speed up ssvm startup

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

[DaanHoogland]

this is only ever called with a StartupSecondaryStorageCommand so can we change the parameter type and skip the class check?

[DaanHoogland]

is this only ever working on one dowload job? it seems we are canceling the download check for someone else here.

[yadvr]

I think it may cause some issue if we don't do this, esp in env with very large no. of templates, volumes, snapshots - pl discuss on dev/users@ @ravening

[yadvr]

Ping @ravening

[ravening]

@weizhouapache you have any feedback on this pr?

[yadvr]

Pl discuss on dev@, in my opinion this should be closed as postponing check isn't something we would want. The tradeoff of speedup vs check needs to be discussed.

[weizhouapache]

Pl discuss on dev@, in my opinion this should be closed as postponing check isn't something we would want. The tradeoff of speedup vs check needs to be discussed.

@ravening
maybe I miss something, I think this is good (it has been used for many years as far as I know).
anyway, it is not a major bug fix.

[yadvr]

@weizhouapache I'm just being risk-averse :) I see that checks are only postponed - but I worry if not doing checks at the time of initial connection causes any failures? For example, you allow the agent to connect and it starts doing some storage related operation, and later the post-connect thread/check runs and finds out we shouldn't have connected, or it fails but since the agent is connected, agent continues to process new commands? (a case can be the template/volume scanning logic times out, but the connect is still connected so agent gets some new operation say re-download template from a URL which is wrong/404 etc and it ends up overwriting existing files?)

[weizhouapache]

@weizhouapache I'm just being risk-averse :) I see that checks are only postponed - but I worry if not doing checks at the time of initial connection causes any failures? For example, you allow the agent to connect and it starts doing some storage related operation, and later the post-connect thread/check runs and finds out we shouldn't have connected, or it fails but since the agent is connected, agent continues to process new commands? (a case can be the template/volume scanning logic times out, but the connect is still connected so agent gets some new operation say re-download template from a URL which is wrong/404 etc and it ends up overwriting existing files?)

@rhtyd these are very good questions.
@ravening are you ok to close this pr ? the issue this pr aims to fix is, SSVM will be Up only if all imags/volumes are checked which I think it is not a major issue.

[ravening]

closing it after discussion