OS Policy Assignment template still missing debian:13 (trixie) inventoryFilter

[blackgnezdo]

Summary

The Google-managed Ops Agent OS Policy Assignment template still does not include a debian:13 (trixie) inventoryFilter, six months after a Google engineer indicated work was in progress in the closing comment on #2060:

"We are working on the OS policy support for Debian 13 right now... Will update here once ready." — @LujieDuan, 2025-11-04

Because the auto-provisioned goog-ops-agent-policy has allowNoResourceGroupMatch: true, trixie VMs that carry the goog-ops-agent-policy label silently report COMPLIANT while no agent is ever installed. This is a particularly nasty failure mode: the operator looks at the OS Config compliance UI, sees green, and assumes the agent is healthy.

Filing a narrow, OS-policy-only follow-up since #2060 itself is closed (the binary side shipped in 2.61.0).

Reproduction

1. Create a Compute Engine VM from debian-cloud/debian-13.
2. Apply the documented label: goog-ops-agent-policy=v2-x86-template-1-4-0 (or =true).
3. Wait for OS Config to converge.
4. SSH to the VM:

   $ systemctl is-active google-cloud-ops-agent
   inactive
   $ dpkg -l | grep -E 'ops-agent|stackdriver|fluentd'
   (none)
   $ systemctl is-active google-osconfig-agent
   active
   

5. Check OS-Config compliance:

   $ gcloud alpha compute os-config instance-os-policies-compliances describe <vm> \
       --location=<zone> --project=<proj> \
       --format=json | jq '.osPolicyCompliances[] | select(.osPolicyId=="goog-ops-agent-policy")'
   {
     "osPolicyAssignment": ".../osPolicyAssignments/goog-ops-agent-v2-x86-template-1-4-0-<region>@...",
     "osPolicyId": "goog-ops-agent-policy",
     "state": "COMPLIANT"
   }
   

What the policy actually contains

Dumped via gcloud compute os-config os-policy-assignments describe goog-ops-agent-v2-x86-template-1-4-0-<region> — the osPolicies[0].resourceGroups[] cover:

• centos:8, rocky:8.*, rhel:8.*
• rocky:9.*, rhel:9.*
• sles:12.*
• sles:15.*, opensuse-leap:15.*
• debian:11 (distribution google-cloud-ops-agent-bullseye-2)
• debian:12 (distribution google-cloud-ops-agent-bookworm-2)
• ubuntu:18.04, 20.04, 22.04, 24.04, 24.10
• windows:10.*, windows:6.*

No debian:13. Combined with allowNoResourceGroupMatch: true on the policy, trixie matches no resource group and is reported COMPLIANT-with-no-action.

What is already in place upstream

• Agent binary supports trixie since 2.61.0 (Debian 13 support #2083, 2025-10-14).
• Apt repository already exists: https://packages.cloud.google.com/apt dists/google-cloud-ops-agent-trixie-2/Release returns 200, and packages such as google-cloud-ops-agent 2.66.0-trixie are available there.

So the only remaining gap is the auto-provisioned OS Policy template — Google has everything it needs to add a debian:13 resourceGroup mirroring the existing debian:12 one.

Workaround (verified)

A custom OS Policy Assignment scoped to osShortName=debian, osVersion=13 works. Example resource group:

resources:
  - id: add-repo
    repository:
      apt:
        archiveType: DEB
        uri: https://packages.cloud.google.com/apt
        distribution: google-cloud-ops-agent-trixie-2
        components: [main]
        gpgKey: https://packages.cloud.google.com/apt/doc/apt-key.gpg
  - id: install-pkg
    pkg:
      desiredState: INSTALLED
      apt:
        name: google-cloud-ops-agent

Verified end-to-end on a fleet of 27 personal Compute Engine VMs (21 trixie + 6 non-trixie). Within ~12 minutes of creating the assignment, all 21 trixie VMs converged from "no agent installed, COMPLIANT against goog-managed template" to actively reporting agent.googleapis.com/agent/uptime with google-cloud-ops-agent-{logging,metrics}/2.66.0-trixie. On a sample VM:

$ dpkg -l | grep google-cloud-ops-agent
ii  google-cloud-ops-agent           2.66.0~debian13   amd64
$ systemctl is-active google-cloud-ops-agent
active

Strongly recommend removing the goog-ops-agent-policy label from trixie VMs that use a custom policy, since the COMPLIANT-but-no-op behaviour will silently override observability if Google later re-enables it under a label name we already use.

Asks

1. Bump the goog-managed OS Policy Assignment template to add a debian:13 resourceGroup. The debian:12 group should be a near drop-in template (swap bookworm-2 → trixie-2).
2. Independently of the fix: please consider treating "no resourceGroup matches & policy was applied" as NON_COMPLIANT (or at least surface a warning) rather than COMPLIANT. The current behaviour makes "agent never installed" indistinguishable from "agent installed and healthy" in the OS Config UI.

Environment

• VM image family: debian-cloud/debian-13
• Google Cloud SDK 566.0.0
• Region: us-central1
• Date observed: 2026-05-10

[LujieDuan]

Thanks for reporting the issue!

1. OS Policy template has been updated to 1-7-0 with Debian 13 support. To use it, you can create any Debian 13 VM and let the checkbox for "Install Ops Agent for Monitoring and Logging" checked. The latest version of the policy will be created and the new label/value will be added to this VM.
2. Thanks for the feedback! While we investigate this with the OS Config UI, I want to suggest Use agent policies (GA) for examples of creating policy targeting a specific set of VMs, and use the VM Dashboard to monitor the installation status of Ops Agent on individual VMs.

[blackgnezdo]

Thanks @LujieDuan — wanted to confirm we're interpreting the directions correctly because two things we tried didn't produce the expected behavior in our project:

1. Set the label on an existing Debian 13 VM to goog-ops-agent-policy=v2-x86-template-1-7-0. Waited 5 minutes. No new goog-ops-agent-v2-x86-template-1-7-0-<zone> OS Policy Assignment appeared.
2. Created a fresh Debian 13 VM via gcloud compute instances create with --labels=goog-ops-agent-policy=v2-x86-template-1-7-0. Waited 20 minutes. Still only the existing goog-ops-agent-v2-x86-template-1-4-0-us-central1-a assignment in the project; no 1-7-0 assignment auto-provisioned.

In both cases the agent did not get installed via Google's policy (we have our own custom OS Policy Assignment covering this gap, which is what's working today).

Reading your message again: "create any Debian 13 VM and let the checkbox … checked" — is the Console "Install Ops Agent" checkbox the only entry point that triggers provisioning of a new template version into a project? Setting the label via API doesn't seem to be enough on its own. Want to make sure we're not missing a step before we treat this as a docs/feature gap.

Agent version 20260427.03-g1.