Optional appendix: OSV PULP_MANIFEST polling (advanced)
|
Optional / advanced — instructor or automation-focused content. Core learners complete 2.2 with the scored OSV and do not need this appendix. Use it to teach the field PoV automation implication: new remediated OSV files can trigger tickets or rebuild pipelines without binding the workshop to any customer ITSM product. |
Why poll the OSV manifest?
Lightwell Network publishes machine-readable OSV records for the Java Remediated stream at https://packages.redhat.com/lightwell/osv/java/remediated. Beside individual OSV JSON files, the repository exposes a Pulp-style PULP_MANIFEST listing those files.
When the manifest checksum changes, something new (or updated) landed in the OSV path—often a new fixed event naming a .rhlw-* pin you can feed into 2.2.
Generic automation story (map to your local ticketing / Git workflow):
-
Poll
https://packages.redhat.com/lightwell/osv/java/remediated/PULP_MANIFESTon a schedule -
Compare SHA-256 (or equivalent) to the last known value
-
On change, create a ticket and/or open a merge request / trigger a rebuild pipeline
-
A human or bot runs 2.2 steps: read
fixed, pin, rebuild
Canonical endpoints
| Item | Value |
|---|---|
OSV base (Java remediated) |
|
Manifest |
|
Example OSV object path |
|
Auth |
|
RHDP labs may use seeded OSV JSON in Nexus / ConfigMap lightwell-sample-osv instead of live packages.redhat.com. Polling live manifests needs network + membership; the scripts still document the production shape.
Shell helper (single shot)
From a GitOps / content checkout with network access:
chmod +x tools/osv-eval/scripts/*.sh
# Optional when the remote requires auth (never commit these):
# export LW_USERNAME=... LW_PASSWORD=...
# Override base only if pointing at a mirror:
# export OSV_BASE=https://packages.redhat.com/lightwell/osv/java/remediated
./tools/osv-eval/scripts/poll-pulp-manifest.sh
Behavior:
-
First run — stores checksum under
~/.cache/lightwell-osv-eval/and prints an initialization message -
Later run with unchanged manifest —
No change -
Later run with changed manifest — prints a generic hook message: open a ticket / trigger a rebuild pipeline
Optional continuous poll (instructor workstation):
INTERVAL_SEC=300 ./tools/osv-eval/scripts/poll-pulp-manifest.sh
Optional generic webhook (JSON text field only — no product-specific schema required):
WEBHOOK_URL='https://example.invalid/hooks/osv' \
./tools/osv-eval/scripts/poll-pulp-manifest.sh
Ansible-style poll (automation narrative)
Same checksum compare using ansible.builtin.uri (AAP-friendly pattern, still generic):
ansible-playbook tools/osv-eval/playbooks/poll-osv-manifest.yml \
-e osv_base=https://packages.redhat.com/lightwell/osv/java/remediated \
-e lw_username="{{ lookup('env','LW_USERNAME') }}" \
-e lw_password="{{ lookup('env','LW_PASSWORD') }}"
On checksum change the playbook prints a debug message to open a ticket / trigger a rebuild pipeline. Customize the hook outside this repository (your org’s ticketing or CI)—do not hard-code customer tool names into the catalog.
What to do after a change is detected
Treat the poll as a signal, then reuse 2.2:
-
Fetch or locate the new/updated OSV JSON (path under
https://packages.redhat.com/lightwell/osv/java/remediatedor your enterprise mirror) -
Run
./tools/osv-eval/scripts/osv-pin.sh <osv.json>and confirmfixed_versioncontains.rhlw- -
Diff sources (
diff-sources.sh --fixtureoffline, or--fetchwhen jars exist) -
Open a merge request that updates the application pin; rebuild with Remediated Maven profiles
-
Let Track 4–6 pipeline and admission gates enforce the remediated pin before GitOps promotion
Explicit non-goals
-
Binding this workshop to a named ITSM, chat, or CMDB product
-
Replacing 2.2’s scored OSV exercise for RHDP learners
-
Polling fictional channel names — only Validated / Remediated / Java OSV remotes apply
Related
-
Toolkit README:
tools/osv-eval/README.md -
Canonical OSV remote:
https://packages.redhat.com/lightwell/osv/java/remediated