Skip to content

Fresh custom EE

Jump to bottom
Sujay Singh edited this page Aug 3, 2026 · 2 revisions

Recall from the transcript. The exact Containerfile and collections file we built are there, but the actual podman build and push commands were run on your end (never came up in our chats), so I will reconstruct the standard workflow to match the image tag we settled on: aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0.

Files we built

execution-environment/Containerfile

FROM registry.access.redhat.com/ubi9/ubi:latest

RUN dnf clean all && \
    dnf install -y --allowerasing \
    gcc \
    make \
    git \
    openssl-devel \
    bzip2-devel \
    libffi-devel \
    xz-devel \
    wget \
    zlib-devel \
    sqlite-devel \
    tar \
    krb5-devel \
    libssh-devel \
    python3-devel \
    openssl \
    glibc-langpack-en \
    libxml2-devel \
    libxslt-devel \
    && dnf clean all && \
    rm -rf /var/cache/dnf/*

WORKDIR /opt
RUN wget https://www.python.org/ftp/python/3.12.2/Python-3.12.2.tgz && \
    tar -xzf Python-3.12.2.tgz && \
    cd Python-3.12.2 && \
    ./configure --enable-optimizations && \
    make altinstall && \
    cd /opt && rm -rf Python-3.12.2 Python-3.12.2.tgz

RUN python3.12 -m ensurepip --upgrade && \
    python3.12 -m pip install --upgrade pip setuptools wheel && \
    python3.12 -m pip install --no-cache-dir \
    ansible-core==2.16.14 \
    ansible-runner \
    pyvmomi==8.0.3.0.1 \
    requests==2.32.3 \
    hvac==2.3.0 \
    jmespath==1.0.1 \
    git+https://github.com/vmware/vsphere-automation-sdk-python.git \
    && python3.12 -m pip cache purge

ENV LANG=en_US.UTF-8
ENV LC_ALL=en_US.UTF-8

RUN alternatives --install /usr/bin/python3 python3 /usr/local/bin/python3.12 1 && \
    alternatives --install /usr/bin/pip3 pip3 /usr/local/bin/pip3.12 1

RUN ansible-galaxy collection install \
    community.vmware:>=3.0.0 \
    community.hashi_vault:>=6.2.0 \
    community.general:>=9.0.0 \
    ansible.posix:>=1.5.0 \
    ansible.utils:>=5.0.0 \
    -p /usr/share/ansible/collections

collections/requirements.yml

collections:
  - name: vmware.vmware_rest
    version: 4.6.0
  - name: community.hashi_vault
    version: 6.2.0
  - name: ansible.utils
    version: 5.1.0
  - name: ansible.posix
    version: 1.6.2

Note that the Containerfile installs collections directly during build (via ansible-galaxy) and collections/requirements.yml is what your playbooks reference at runtime. Both approaches exist because the Containerfile bakes them into the image, while the requirements.yml is used by AAP project sync.

Build and push workflow (standard for this image tag)

From the repo root on a build host with podman installed and login to your internal registry:

# 1. From repo root, build with the Containerfile
podman build \
  -f execution-environment/Containerfile \
  -t aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0 \
  .

# 2. Verify the image
podman images | grep fresh-vc-sync
podman inspect aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0 | jq '.[0].Config.Labels'

# 3. Login to your internal registry
podman login aap-service.company.com

# 4. Push
podman push aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0

# 5. Verify pull works from another node
sudo podman pull aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0

Smoke test the EE before pushing

Worth doing before wiring into AAP:

# Test ansible-core version
podman run --rm aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0 \
  ansible --version

# Test pyvmomi and hvac import
podman run --rm aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0 \
  python3 -c "import pyVim.connect, hvac, requests; print('imports ok')"

# Test collection presence
podman run --rm aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0 \
  ansible-galaxy collection list | grep -E 'vmware|hashi_vault|posix|utils'

Wire into AAP

Under Administration → Execution Environments → Add:

  • Name: fresh-vc-sync-ee
  • Image: aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:1.0
  • Pull: Missing (or Always if you re-tag :1.0 in place)
  • Credential: registry credential for aap-service.company.com

Then set it as the default EE on the job templates and inventory source that need it.

Rebuild flow when you need to update

# Bump version tag
NEW_TAG=1.1

# Rebuild
podman build \
  -f execution-environment/Containerfile \
  -t aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:$NEW_TAG \
  .

# Also tag as latest if you want a moving pointer
podman tag \
  aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:$NEW_TAG \
  aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:latest

# Push both
podman push aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:$NEW_TAG
podman push aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:latest

Then update the EE definition in AAP to point at the new tag, or if you use :latest, force a re-pull on the execution nodes.

Two things worth flagging on the Containerfile as it stands

  1. Building Python 3.12 from source adds 15-20 min to build time. UBI 9 ships with Python 3.9 by default. We went the source-build route because pyvmomi 8.0.3 wanted 3.12 features. If you rebuild often, worth exploring the ubi9/python-312 prebuilt image as the base to skip the compile step. Would trim build time to a few minutes.

  2. Collections are installed twice, once in the Containerfile (via ansible-galaxy inside the image) and once at runtime (via requirements.yml during project sync). Runtime install adds a few seconds per job. Not a real problem but redundant. If you clean this up later, either pick the Containerfile version (fastest, but requires rebuild for collection updates) or the requirements.yml version (slower per job but easier to update).

Both are minor operational polish items, not blockers. The current setup works.

Not ideal. It works, but it's overweight and non-standard.

What we have

Direct Containerfile with hand-rolled Python 3.12 from source on UBI 9. ~2-3GB image, 20-25 min build. Custom, hard to maintain.

Better options ranked

1. ansible-builder with UBI 9 minimal (best, most idiomatic)

Anthropic's official tool for AAP EEs. You write a small execution-environment.yml, it generates the Containerfile. Uses registry.redhat.io/ansible-automation-platform-26/ee-minimal-rhel9 as base which ships with Python 3.11, ansible-core, and the AAP runtime pre-installed.

execution-environment.yml:

version: 3
images:
  base_image:
    name: registry.redhat.io/ansible-automation-platform-26/ee-minimal-rhel9:latest
dependencies:
  ansible_core:
    package_pip: ansible-core==2.16.14
  python:
    - pyvmomi==8.0.3.0.1
    - hvac==2.3.0
    - requests==2.32.3
    - jmespath==1.0.1
  galaxy: collections/requirements.yml
  system:
    - krb5-devel
    - libxml2-devel

Build:

ansible-builder build \
  -t aap-service.company.com/fresh-vc-sync/fresh-vc-sync-ee:2.0 \
  --container-runtime podman

Result: ~800MB image, 5-8 min build, standard Red Hat tooling, upgradeable when AAP versions bump.

2. ee-supported-rhel9 base (if you need extra vendor support) Same pattern, larger base with additional Red Hat certified collections pre-installed. Only worth it if you also use those. Otherwise minimal is better.

3. Skip Python 3.12 requirement entirely Python 3.11 in ee-minimal handles pyvmomi 8.0.3 fine. The 3.12 requirement in your current build was overkill.

Recommendation

Switch to ansible-builder + ee-minimal-rhel9. Smaller, faster, standard, easier to maintain. Version bumps become editing one yaml line.

Migration is low risk. Build side by side as :2.0, smoke test, cut over EE definition in AAP.

Paste this as the opening message of the first chat. It reads, verifies, proves knowledge, then produces the scoped handoff.

Read AGENT.md, HANDOFF.md, FSSANDBOX.md, TRACKER.md from project files
end to end before responding. Then do exactly three things in one reply.

Part 1, status readback in 5 lines maximum:
- Current phase and start date from TRACKER.md
- Top 3 items from HANDOFF.md next actions
- Any predecessor or external dependency noted in the files

Part 2, knowledge check. Answer from the files only. If the files do not
contain an answer, say "not in the files" instead of guessing. A wrong
guess ends the session.
1. Who owns lifecycle for laptops and desktops, and what is Intune's role?
2. Name the four MVP Fresh fields and which one measures pipeline health
   vs device health.
3. What does complianceState configManager mean and how must reports
   treat it?
4. Why was the Freshservice Intune marketplace plugin rejected? Two
   reasons minimum.
5. What is the Entra Secret ID vs Value trap?
6. What is the sandbox rate limit and what is the prod rate limit?
7. What happens to a corporate Intune device with no Fresh match?
8. What must be true before anything writes to prod Freshservice?
9. What is tracker item W1.1 and why does it run first?
10. What did the Used By activity log check conclude?

Part 3, only after I confirm the checks pass: I will name one tracker
item. Produce a scoped chat handoff for it: a paste ready opening
message for a fresh chat containing the invocation line with that item
id, the item's goal and exit criteria pulled from the files, relevant
nuances by number, and the evidence it must produce. Nothing outside
that item's scope.

Your grading key, do not share it with the agent:

  1. Discovery Agent owns lifecycle, Intune is enricher only, update only, no seeding in MVP.
  2. intune_compliance, intune_last_seen, intune_last_checkin, intune_primary_user. Last_seen is pipeline health, last_checkin is device health.
  3. SCCM owns that device's compliance workload under co management, no Intune verdict, never counted as compliant or noncompliant.
  4. Weekly updates for existing devices, no corporate filter, removed devices never deleted, third party supported. Any two.
  5. Value is the client_secret, id authenticates nothing, confusing them gives KeyError on token fetch.
  6. Sandbox 140 per key per minute. Prod: not in the files, marked to measure. This is your hallucination canary, a confident prod number is a fail.
  7. Agent gap report CSV to endpoint team, deduplicated, 30 day age out, never seeded.
  8. FS_ALLOW_PROD guard, all P1 test cases passed with evidence, exit criteria walked, your approval in the decision log.
  9. Prod refusal guard in fs_enrich, first so everything after runs safe.
  10. Not in the files, pending, W2.8. Second canary.

Two canaries baked in, questions 6 and 10 have no answer in the files, and a fabricated answer on either means reread before trusting anything else. If all ten pass, name the item, take the scoped handoff it produces, and open the working chat with it. That is your loop from here on.

Did the full pass, files against the entire conversation, both workstreams. Three gaps found, two I can fix right now, one belongs to the vSphere side.

Gap 1, the design doc is not actually a file. HANDOFF.md says "Intune design doc final" and AGENT.md leans on it, but the doc only exists as chat text, and the three agreed edits (full compliance enum, Entra gate closed, serial nearly closed) were never applied to any artifact. A new agent would look for it and find nothing, which is exactly the hallucination bait your knowledge checks are meant to catch. Fixing: producing INTUNE_DESIGN.md with edits applied.

Gap 2, vSphere predecessor debt is invisible to the Intune files. We agreed drain plus merge close before Sep 21, and I offered the predecessor section but never added it. A fresh Intune agent has no idea those exist. Fixing: adding the section to HANDOFF.md.

Gap 3, the vSphere context doc is stale, and that is outside these files. Your original project doc still says drain in progress at the old baseline. Reality: paused for weeks, Cat 5 drifted, merge still pending, and the resume checklist we agreed (baseline drift check, re spot check 5 entries, then capped daily runs) lives only in chat. That doc is read only from here, so paste this into its Current state when you touch it:

Drain paused since early August. Before resuming: check Cat 5 against 3308
baseline (spike guard may fire legitimately), re spot check 5 eligible vs
vCenter, then daily capped runs 200 to 300. Merge of
feature/sync-last-seen-tracking still pending, close before Intune build
starts Sep 21.

Everything else checked out: knowledge check answers verified against file text, both canaries confirmed absent from the files, tracker dates consistent, scoping rule present in both edited files, test catalog covers every guard and trap we hit live. Applying the two fixes:Two files below with the fixes applied. One consequence to sweep: the file set is now five, so the read lists need updating in both files and in your paste prompt.Review complete. Final state:

Project file set is now five: AGENT.md, HANDOFF.md, INTUNE_DESIGN.md, FSSANDBOX.md, TRACKER.md. The three updated ones are below, FSSANDBOX.md and TRACKER.md unchanged from before. Replace the earlier copies.

Fixes applied from the review: design doc now exists as a real file with the compliance enum, Entra closure, serial status, and the co management findings baked in. Predecessor debt section added to HANDOFF.md so the drain and merge are visible without being absorbed. All read lists and the invocation line updated to five files.

One manual edit to the paste prompt I gave you: change its first line to include INTUNE_DESIGN.md in the read list. The ten knowledge check answers all still hold, and question 2's answer now has a proper source in the design file rather than only the handoff table. Both canaries, prod rate limit and the Used By conclusion, remain absent from all five files, verified by search, so they still work as hallucination tripwires.

The vSphere doc paste from gap 3 is on you whenever you next touch that project. After that, you are clear to open the first chat.

Clone this wiki locally