Revert "fix(localdns): wait for resolv.conf update after networkctl reload to prevent race condition (#7749)"

This reverts commit bcdecfa.

Author: mxj220

.github/copilot-instructions.md

@@ -0,0 +1 @@
+../AGENTS.md

.github/copilot-instructions.md

@@ -136,90 +136,6 @@ Analyze PRs for these compatibility scenarios:
   - Package manager assumptions (apt vs dnf/tdnf)
   - Systemd differences between distributions
 
-**5. Package/Dependency Update PRs (Renovate)**
-- **Context**: Renovate bot automatically creates PRs to update component versions in `parts/common/components.json`. These components are cached on VHDs during build and directly affect node stability, GPU workloads, networking, and security. Updated packages are downloaded from `packages.aks.azure.com` or upstream registries during VHD build.
-- **What to check**: Every version bump—even patch versions—can introduce regressions that affect production nodes.
-- **Analysis steps for every package update PR**:
-  1. **Identify the component and version change**: Parse the diff in `parts/common/components.json` to extract exact old → new versions for each OS/release entry.
-  2. **Determine the update type**: Classify as major, minor, or patch using semver. Major and minor updates carry higher risk than patch updates.
-  3. **Research upstream changelog**: Look up the project's release notes, changelog, or GitHub releases to understand what changed between the old and new versions. Summarize:
-     - New features introduced
-     - Bug fixes included
-     - Breaking changes or deprecations
-     - Security fixes (CVEs patched)
-  4. **Assess OS coverage**: Check if the update covers all OS variants where the component is used (Ubuntu 22.04, 24.04, Azure Linux 3.0, etc.). Flag if some OS entries are updated but others are not — partial updates can cause inconsistency across node pools.
-  5. **Evaluate VHD size impact**: For components downloaded as binaries or packages, consider whether the new version significantly increases VHD size. Large size increases can affect VHD build time and storage costs.
-  6. **Check for configuration or API changes**: If the component exposes configuration files, CLI flags, systemd units, or APIs consumed by CSE scripts, verify that the update doesn't change defaults or remove options that provisioning scripts depend on.
-  7. **Verify download URL validity**: Confirm that the `downloadLocation` and `downloadURIs` structure in components.json remains valid for the new version. New versions sometimes change the artifact naming convention or repository layout.
-
-- **Risk assessment for package updates**:
-  - 🔴 **High Risk**: Major version bumps, components critical to node boot (kubelet, containerd, runc), GPU drivers (nvidia-driver, dcgm-exporter), or networking (azure-cni, cilium). Also high risk if upstream changelog mentions breaking changes or behavioral changes.
-  - 🟡 **Medium Risk**: Minor version bumps of non-critical components, updates that only affect specific OS variants, or updates where upstream changelog shows feature additions that could subtly change behavior.
-  - 🟢 **Low Risk**: Patch version bumps with only bug fixes or security patches, no breaking changes in upstream changelog, and full OS coverage.
-
-- **Review output for package update PRs must include a detailed version diff analysis**:
-
-  **Header:**
-  ```
-  ## Package Update Analysis: <component-name>
-  **Version change**: X.Y.Z → A.B.C (<major|minor|patch> update)
-  **OS variants affected**: Ubuntu 22.04, Ubuntu 24.04, Azure Linux 3.0 (list all)
-  **OS variants NOT updated**: <list any missing, or "None — full coverage">
-  ```
-
-  **Detailed changelog between versions:**
-  Use web search, GitHub releases, or upstream project documentation to find the exact differences between the old and new version. Present each change as a line item with its own risk tag:
-
-  ```
-  ### Changes between X.Y.Z and A.B.C
-
-  | Change | Description | Risk |
-  |--------|-------------|------|
-  | Feature | <brief description of new feature> | 🟢 Low / 🟡 Medium / 🔴 High |
-  | Bug fix | <brief description of bug fixed> | 🟢 Low / 🟡 Medium / 🔴 High |
-  | Breaking | <description of breaking change> | 🔴 High |
-  | Security | CVE-YYYY-XXXXX: <description> | 🟢 Low / 🟡 Medium / 🔴 High |
-  | Deprecation | <what was deprecated and migration path> | 🟡 Medium / 🔴 High |
-  | Config change | <default value changed or option removed> | 🟡 Medium / 🔴 High |
-  | Performance | <perf improvement or regression> | 🟢 Low / 🟡 Medium |
-  ```
-
-  For each individual change, assess risk by considering:
-  - Does it alter runtime behavior on AKS nodes?
-  - Does it change CLI flags, config file formats, or systemd unit behavior that CSE scripts depend on?
-  - Does it affect GPU workloads, networking, container runtime, or kubelet interaction?
-  - Could it increase binary size significantly (VHD bloat)?
-  - Does it introduce new system dependencies or kernel requirements?
-
-  **If upstream changelog is unavailable**, explicitly state: _"Upstream changelog not found for this version range. Manual testing recommended before merge."_
-
-  **Overall risk assessment:**
-  ```
-  ### Overall Risk: 🟢 Low / 🟡 Medium / 🔴 High
-  **Justification**: <1-2 sentence summary of why this risk level was chosen>
-  **Recommendation**: Approve / Request more info / Flag for manual testing
-  ```
-
-  **Example** (for a PR like dcgm-exporter 4.7.1 → 4.8.0):
-  ```
-  ## Package Update Analysis: dcgm-exporter
-  **Version change**: 4.7.1 → 4.8.0 (minor update)
-  **OS variants affected**: Ubuntu 22.04, Ubuntu 24.04
-  **OS variants NOT updated**: Azure Linux 3.0 (still on 4.7.1-1.azl3) — flag for follow-up
-
-  ### Changes between 4.7.1 and 4.8.0
-  | Change | Description | Risk |
-  |--------|-------------|------|
-  | Feature | Added support for new DCGM field IDs for Blackwell GPUs | 🟢 Low |
-  | Feature | New metrics endpoint configuration options | 🟡 Medium |
-  | Bug fix | Fixed memory leak in long-running metric collection | 🟢 Low |
-  | Deprecation | Removed legacy CSV export format | 🟡 Medium |
-
-  ### Overall Risk: 🟡 Medium
-  **Justification**: Minor version bump of GPU monitoring component. No breaking changes to core metrics pipeline, but Azure Linux 3.0 is not updated which creates version skew across OS variants.
-  **Recommendation**: Approve, but file follow-up issue for Azure Linux 3.0 alignment.
-  ```
-
 ### Analysis Approach
 
 **Dynamic Dependency Tracing**:
@@ -253,22 +169,8 @@ Provide targeted inline comments on specific lines where you detect issues:
 - Include actionable next steps (e.g., "Verify this function is not used by checking references in `vhdbuilder/packer/`")
 
 **Risk indicators to include:**
-
-- **Severity** (pick one):
-  - 🔴 **High Risk** — Could break production VM provisioning, cause node failures, or introduce security vulnerabilities
-  - 🟡 **Medium Risk** — Could cause issues in specific configurations, edge cases, or degrade performance
-  - 🟢 **Low Risk** — Unlikely to cause issues but worth noting for awareness
-
-- **Category** (pick one):
-  - 🔧 **Script Logic** — Syntax errors, incorrect commands, broken control flow, wrong exit codes
-  - 🖥️ **Cross-OS** — Incompatibility between Ubuntu, Azure Linux/Mariner, or Windows
-  - 🌐 **External Dependency** — Unauthorized downloads, missing components.json entries, broken URLs
-  - 🧪 **Test Coverage** — Missing or insufficient test coverage for changed behavior
-  - 📦 **Package Update** — Component version changes, upstream regressions, VHD size impact
-  - 🔄 **Backward Compatibility** — Breaking changes affecting VHDs in production (6-month window)
-  - 🔒 **Security** — Credential exposure, privilege escalation, insecure defaults
-  - ⚡ **Performance** — VHD build time regression, node provisioning latency increase
-  - 🏗️ **Architecture** — Structural changes affecting multiple components or deployment modes
+- Severity: 🔴 High Risk | 🟡 Medium Risk | 🟢 Low Risk
+- Category: Script Logic | Cross-OS | External Dependency | Test Coverage | etc.
 
 **Only comment when you have substantive findings** - avoid noise on trivial or obviously safe changes.
 

AGENTS.md

@@ -43,18 +43,16 @@ func GetExpectedPackageVersions(packageName, distro, release string) []string {
 	release = strings.ReplaceAll(release, ".", "\\.")
 
 	for _, packageItem := range packages.Array() {
-		// Check if versionsV2 exists. Assume the DEFAULT OS variant.
-		versions := packageItem.Get(fmt.Sprintf("%s.DEFAULT/%s.versionsV2", distro, release)).Array()
-		if len(versions) == 0 {
-			versions = packageItem.Get(fmt.Sprintf("%s.%s.versionsV2", distro, release)).Array()
-		}
-
-		for _, version := range versions {
-			// get versions.latestVersion and append to expectedVersions
-			expectedVersions = append(expectedVersions, version.Get("latestVersion").String())
-			// get versions.previousLatestVersion (if exists) and append to expectedVersions
-			if version.Get("previousLatestVersion").Exists() {
-				expectedVersions = append(expectedVersions, version.Get("previousLatestVersion").String())
+		// check if versionsV2 exists
+		if packageItem.Get(fmt.Sprintf("%s.%s.versionsV2", distro, release)).Exists() {
+			versions := packageItem.Get(fmt.Sprintf("%s.%s.versionsV2", distro, release))
+			for _, version := range versions.Array() {
+				// get versions.latestVersion and append to expectedVersions
+				expectedVersions = append(expectedVersions, version.Get("latestVersion").String())
+				// get versions.previousLatestVersion (if exists) and append to expectedVersions
+				if version.Get("previousLatestVersion").Exists() {
+					expectedVersions = append(expectedVersions, version.Get("previousLatestVersion").String())
+				}
 			}
 		}
 	}

e2e/components/components.go

@@ -942,16 +942,6 @@
             ],
             "downloadURL": "https://github.com/oras-project/oras/releases/download/v${version}/oras_${version}_linux_${CPU_ARCH}.tar.gz"
           }
-        },
-        "azurelinux": {
-          "OSGUARD/v3.0": {
-            "versionsV2": [
-              {
-                "renovateTag": "<DO_NOT_UPDATE>",
-                "latestVersion": "<SKIP>"
-              }
-            ]
-          }
         }
       }
     },
@@ -1039,15 +1029,15 @@
             "versionsV2": [
               {
                 "renovateTag": "name=moby-containerd, repository=production, os=ubuntu, release=22.04",
-                "latestVersion": "1.7.30-ubuntu22.04u2"
+                "latestVersion": "1.7.30-ubuntu22.04u1"
               }
             ]
           },
           "r2004": {
             "versionsV2": [
               {
                 "renovateTag": "name=moby-containerd, repository=production, os=ubuntu, release=20.04",
-                "latestVersion": "1.7.30-ubuntu20.04u2"
+                "latestVersion": "1.7.30-ubuntu20.04u1"
               }
             ]
           }
@@ -1080,14 +1070,6 @@
                 "latestVersion": "2.0.0-16.azl3"
               }
             ]
-          },
-          "OSGUARD/v3.0": {
-            "versionsV2": [
-              {
-                "renovateTag": "<DO_NOT_UPDATE>",
-                "latestVersion": "<SKIP>"
-              }
-            ]
           }
         },
         "azurelinuxkata": {
@@ -1100,16 +1082,6 @@
             ]
           }
         },
-        "flatcar": {
-          "current": {
-            "versionsV2": [
-              {
-                "renovateTag": "<DO_NOT_UPDATE>",
-                "latestVersion": "<SKIP>"
-              }
-            ]
-          }
-        },
         "windows": {
           "ws2019": {
             "versionsV2": [
@@ -1710,7 +1682,7 @@
           }
         },
         "azurelinux": {
-          "DEFAULT/v3.0": {
+          "v3.0": {
             "versionsV2": [
               {
                 "renovateTag": "RPM_registry=https://developer.download.nvidia.com/compute/cuda/repos/azl3/x86_64/repodata, name=datacenter-gpu-manager-4-core, repository=nvidia, os=azurelinux, release=3.0",
@@ -1744,7 +1716,7 @@
           }
         },
         "azurelinux": {
-          "DEFAULT/v3.0": {
+          "v3.0": {
             "versionsV2": [
               {
                 "renovateTag": "RPM_registry=https://developer.download.nvidia.com/compute/cuda/repos/azl3/x86_64/repodata, name=datacenter-gpu-manager-4-proprietary, repository=nvidia, os=azurelinux, release=3.0",
@@ -1778,7 +1750,7 @@
           }
         },
         "azurelinux": {
-          "DEFAULT/v3.0": {
+          "v3.0": {
             "versionsV2": [
               {
                 "renovateTag": "RPM_registry=https://packages.microsoft.com/azurelinux/3.0/prod/cloud-native/x86_64/repodata, name=dcgm-exporter, os=azurelinux, release=3.0",

parts/common/components.json

@@ -111,8 +111,6 @@ Please refer to [components.cue](../../../../schemas/components.cue) for the mos
 }
 #AzureLinuxOSDistro: {
   "v3.0"?:  #ReleaseDownloadURI
-	"DEFAULT/v3.0"?: #ReleaseDownloadURI
-	"OSGUARD/v3.0"?: #ReleaseDownloadURI
 	current?: #ReleaseDownloadURI
 }
 ```
@@ -140,7 +138,6 @@ Here are the explanation of the above schema.
      - In `MarinerOSDistro`, we only have `current` now, which implies that single configurations will be applied to all Mariner release versions. We can distinguish them in needed. Note, we confirmed with Mariner team, Azure Linux 2.0 is reporting itself as `mariner` in the file `/etc/os-release`. So for Azure Linux 2.0 case, it will still read the package versions from `mariner` block.
     - In `AzureLinuxOSDistro`, `v3.0` is for Azure Linux v3.0. `current` is for otherwise but we are not using it now. Azure Linux 2.0 case is described in the `MarinerOSDistro` above. 
     - `DefaultOSDistro` means the default case of OS Distro. If an OSDistro metadata is not defined, it will fetch it from `default`. For example, if a node is Ubuntu 20.04, but we don't specify `ubuntu` in components.json, then it will fetch `default.current`. For another example, if only `default.current` is specified in the components.json, No matter what OSDistro is the node running, it will only fetch `default.current` because it's the default metadata. This provides flexibility while elimiating unnecessary duplication when defining the metadata.
-1. The OS release version can optionally be prefixed with the OS variant. `OSGUARD/v3.0` and `DEFAULT/v3.0` are currently supported for `azurelinux`. The latter specifically matches Azure Linux 3.0 without a variant, i.e. not OS Guard.
 1. In `ReleaseDownloadURI`, you can see 2 keys.
     - `versionsV2`: This is updated from `versions`. You can define a list of `VersionV2` for a particular package. And in the codes, it's up to the feature developer to determine how to use the list. For example, install all versions in the list or just pick the latest one. Note that in package `containerd`, `marinerkata`, the `versionV2s` array is defined as `<SKIP>`. This is to tell the install-dependencies.sh not to install any `containerd` version for Kata SKU.
 	- `downloadURL`: you can define a downloadURL with unresolved variables. For example, `https://acs-mirror.azureedge.net/azure-cni/v${version}/binaries/azure-vnet-cni-linux-${CPU_ARCH}-v${version}.tgz`. But the feature developer needs to make sure all variables are resolvable in the codes. In this example, `${CPU_ARCH}` is resolvable as it's defined at global scope. `${version}` is resovled based on the `versions` list above.

parts/linux/cloud-init/artifacts/README-COMPONENTS.md

@@ -77,7 +77,7 @@ installCredentialProviderFromPMC() {
         os_version="${OS_VERSION}"
     fi
    	PACKAGE_VERSION=""
-    getLatestPkgVersionFromK8sVersion "$k8sVersion" "azure-acr-credential-provider-pmc" "$os" "$os_version" "${OS_VARIANT}"
+    getLatestPkgVersionFromK8sVersion "$k8sVersion" "azure-acr-credential-provider-pmc" "$os" "$os_version"
     packageVersion=$(echo $PACKAGE_VERSION | cut -d "-" -f 1)
 	echo "installing azure-acr-credential-provider package version: $packageVersion"
     mkdir -p "${CREDENTIAL_PROVIDER_BIN_DIR}"

parts/linux/cloud-init/artifacts/azlosguard/cse_install_osguard.sh

@@ -340,8 +340,6 @@ ExecStartPost=/sbin/iptables -P FORWARD ACCEPT
 EOF
 
   mkdir -p /etc/containerd
-  # Remove in case this is an existing symlink
-  rm -f /etc/containerd/config.toml
   if [ "${GPU_NODE}" = "true" ]; then
     # Check VM tag directly to determine if GPU drivers should be skipped
     export -f should_skip_nvidia_drivers