Feature: Azure Linux 3.0: Enhanced Support

[rane-rajasi]

This PR contains changes to support strict SDP in Azure Linux.

How it works:
Strict SDP in auto patching ensures the same set of patches are updated in all regions during a rollout. This is implemented using max_patch_publish_date. An incoming PatchInstallation request, with strict sdp, will receive a max_patch_publish_date, we need to fetch all patches published on or before this date and update them if necessary.

Pending:
[x] BVT test plan

In VM Tests:
[x] Azure Linux 3.0 base support: 2.core.log 2.status.txt
[x] Strict SDP support restricted to Azure Linux 3.0 with min requirements (tdnf support)
     1. don't run SDP on 2. (which would have corresponding in vm tests) - 3.core.log 3.status.txt
     2. if AzLinux 3 with min requirements not met (in vm tests):
         2.1. not achievable - fail - 3.core.log 3.status.txt
         2.2 achievable - make the prerequisites met 2.core.log 2.status.txt
             - if that fails, fail - refer to results in 2.1
     3. if AzLinux with min requirements met (either through action or by default), perform action - (in vm tests) 2.core.log 2.status.txt

[Copilot]

Pull Request Overview

This PR enhances Azure Linux support by introducing stricter SDP handling and snapping time commands in the package management flow.

• Updated command generation to include snapshottime substitution
• Added methods to extract and convert health_store_id to POSIX time in both the package manager and execution configuration
• Expanded test coverage to validate health_store_id processing in various scenarios

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/core/tests/library/LegacyEnvLayerExtensions.py	Added a regex substitution to remove snapshottime from commands
src/core/tests/Test_TdnfPackageManager.py	Added tests to validate health_store_id conversion and behavior
src/core/src/package_managers/TdnfPackageManager.py	Introduced methods for fetching POSIX time and generating commands with snapshottime
src/core/src/core_logic/ExecutionConfig.py	Updated configuration to process and validate dates within health_store_id

[codecov]

Codecov Report

❌ Patch coverage is 98.40000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.83%. Comparing base (3cdffd8) to head (91b6a84).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/core/src/bootstrap/EnvLayer.py	90.90%	1 Missing ⚠️
src/core/src/package_managers/PackageManager.py	66.66%	1 Missing ⚠️
src/core/src/package_managers/YumPackageManager.py	50.00%	1 Missing ⚠️
.../core/src/package_managers/ZypperPackageManager.py	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #318      +/-   ##
==========================================
+ Coverage   93.77%   93.83%   +0.05%     
==========================================
  Files         103      103              
  Lines       17924    18132     +208     
==========================================
+ Hits        16809    17014     +205     
- Misses       1115     1118       +3     

Flag	Coverage Δ
python27	93.82% <98.39%> (+0.05%)	⬆️
python312	93.83% <98.40%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kjohn-msft]

Marking todos discussed offline:

• Distinguish between AzLinux 2.0 and 3.0. Validate in-VM with new code to fork behaviors.
• Distinguish between min-support prereqs within 3.0 and a VM without it in code.
• Implement in-VM update path to get minimum prereqs (without breaking SDP) to get to a supported state to continue the operation as strictly SDP-based. Test in-VM on pre-req-meeting VM and non-pre-req-meeting VM.
• Manage BVT test plan for the above mainline conditions.

[kjohn-msft]

Comments inline.

Also, generic comment for something I see across everyone's PRs across code-bases - the articulation of the unit test plan (this is how my code can fail and this is how my UT plan covers it) as a doc is super valuable to all reviewers and speeds up reviews. No action on this PR, but general thought. The reason for this is the PR reviewer (if they're doing their job) needs to come up with their own mental model of failure conditions, find if all of their expectations are sitting somewhere in the code, and then provide feedback. Vs. a shared context of plain english plan = discussion over the plan vs. low level inferences and maybe misses. This is just an extension of how complex code without reviewed design isn't efficient - same thing on well-done and large test suites.

[rane-rajasi]

Comments inline.

Also, generic comment for something I see across everyone's PRs across code-bases - the articulation of the unit test plan (this is how my code can fail and this is how my UT plan covers it) as a doc is super valuable to all reviewers and speeds up reviews. No action on this PR, but general thought. The reason for this is the PR reviewer (if they're doing their job) needs to come up with their own mental model of failure conditions, find if all of their expectations are sitting somewhere in the code, and then provide feedback. Vs. a shared context of plain english plan = discussion over the plan vs. low level inferences and maybe misses. This is just an extension of how complex code without reviewed design isn't efficient - same thing on well-done and large test suites.

Does this conform with the UT plan: #318 (comment)?

[kjohn-msft]

Two classes of comments

• one must address (architecturally) but not in this PR - has to be the immediately following PR though. This is to progressively get the code in.
• one set of easily addressable comments that can go in immediately

No major flags in iteration 15.

[kjohn-msft]

• Manage BVT test plan for the above mainline conditions

This* + PBI 34535982 will clean the story out.

• mainline conditions have changed since this comment was originally written, so review plan for BVT prior to coding out.