Remove getcwd to load WAAgent properly and not fall to backup#2160
Remove getcwd to load WAAgent properly and not fall to backup#2160gopaljain00 wants to merge 3 commits into
Conversation
@microsoft-github-policy-service agree [company="{Microsoft}"] |
|
@gopaljain00 please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
| if has_importlib_util: | ||
| # For Python 3.5 and later, use importlib | ||
| spec = importlib.util.spec_from_file_location('waagent', agentPath) | ||
| waagent = importlib.util.module_from_spec(spec) |
There was a problem hiding this comment.
This line broke in the last release which was reverted as a part of this rollback.
I suggest you to either checkout from main and then merge your changes(might need conflict resolution) or removed what's undone in this PR
Also, remove files with whitespace changes only from the PR.
There was a problem hiding this comment.
Got it. I will see if we can reproduce the same (+ fix) in UTs.
This PR is a fix for this issue: https://msazure.visualstudio.com/One/_workitems/edit/36801896
(This WI has response from GuestAgent team which provides insights on the possible errors.)
VMBackup uses a library called WAAgent (https://github.com/Azure/WALinuxAgent)
This library comes bundled with the VMBackup extension (present in VMBackup\main\WaagentLib.py), and is loaded by a utility file (VMBackup/main/Utils/WAAgentUtil.py)
WAAgentUtil.py loads WAAgent in 2 steps.
Step-1: Try to load the bundled file by constructing its path -
agentPath = os.path.join(os.getcwd(), "main/WaagentLib.py")Step-2: If above path is not resolved correctly, check if this library is present in the user's VM in the directory:
agentPath = '/usr/sbin/waagent'Ideally, Step-1 should work, and we should not need to reach fallback (i.e Step-2).
The issue here is the path resolution in Step-1 is fragile. It will only work when executed from extension root (as it uses getcwd()). Which might result in loading the fallback.
And it is not guaranteed that the fallback works as expected with our extension as intended as it is coming from User's VM so there can be version mismatch, etc (resulting in missing dependencies such as ShellUtil not defined).
In this PR, I've added changes to:
Some additional changes done: