product-lifecycle: Add plc_lookup.py CLI, migrate to v2 API

[harche]

Summary

• Replaces inline curl/python one-liners in product-lifecycle SKILL.md with a standalone Python CLI (plc_lookup.py) wrapping the Red Hat Product Life Cycle API v2
• Addresses review feedback from PR OTA-1963: skills: Add cluster-update skills (update-advisor, product-lifecycle) #6: v1→v2 migration, all 5 support status types, drop PLCC acronym, proper error handling
• Adds pagination (--limit, --offset) for broad queries
• Includes 46 tests (unit with mocked API + integration against live API)
• Updates update-advisor SKILL.md cross-references

Builds on top of #6 (that PR stays open).

CLI usage

python3 cluster-update/product-lifecycle/scripts/plc_lookup.py products "logging for Red Hat OpenShift"
python3 cluster-update/product-lifecycle/scripts/plc_lookup.py products "OpenShift" --ocp 4.21 --limit 5
python3 cluster-update/product-lifecycle/scripts/plc_lookup.py olm-check --ocp 4.21 --operators '[{"package":"cluster-logging"}]'

Test plan

• All 46 tests pass locally (python3 -m unittest — 19 unit + 17 integration against live API + 10 pagination)
• Verify plc_lookup.py -h shows clean help output
• Verify script works from repo root path
• Verify SKILL.md paths resolve correctly

🤖 Generated with Claude Code

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: harche

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [harche]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[harche]

/hold

will look into this after #6

[harche]

Testing Results

Eval Framework (Agent-in-the-loop)

Ran 12 skill evals via the agentic-skills eval framework using Claude on Vertex AI. Test queries use the exact prompt format CVO proposals send to the agent, with real OLM operator data and readiness JSON.

product-lifecycle (7 evals)

Test Case	Query	Expected	Result
plc_proposal_olm_batch_check	5-operator batch olm-check from proposal context	5 checked, 3 unavailable	✅
plc_cluster_logging_supported	cluster-logging v6.5 lifecycle + OCP 4.21 compat	supported, compatible	✅
plc_web_terminal_compat_check	web-terminal supported version for OCP 4.21	no supported version for 4.21	✅
plc_compliance_operator_status	compliance-operator v1.9 lifecycle status	found, supported	✅
plc_ocp_platform_status	OCP 4.21 platform lifecycle	supported	✅
plc_ocp_old_version_extended	OCP 4.14 lifecycle phase	extended	✅
plc_batch_known_operators_only	2-operator batch check (cluster-logging + web-terminal)	both found, neither EOL	✅

update-advisor (5 evals)

Each test sends a complete readiness JSON (same format CVO produces) and verifies the agent's upgrade decision:

Test Case	Scenario	Expected Decision	Result
advisor_healthy_cluster_recommend	All 9 checks pass, no issues	recommend	✅
advisor_degraded_operator_caution	1 degraded operator (authentication)	caution	✅
advisor_api_deprecation_block	Removed API with 1250 active requests	block	✅
advisor_etcd_unhealthy_block	1 of 3 etcd members not ready	block	✅
advisor_errored_checks_escalate	7 of 9 readiness checks errored (API unreachable)	escalate	✅

All 12 agent evals + 46 unit/integration tests passed.

End-to-End with CVO Readiness Data

Tested the full proposal → readiness → skill pipeline using a custom CVO build from openshift/cluster-version-operator#1395 deployed to a live OCP 4.21.5 cluster on GCP (6 nodes).

Installed OLM operators for testing:

• cluster-logging v6.5.1 (channel: stable-6.5)
• compliance-operator v1.9.0 (channel: stable)
• openshift-pipelines-operator-rh v1.22.0 (channel: latest)
• web-terminal v1.16.0 (channel: fast)
• devworkspace-operator v0.41.0 (channel: fast)

Flow verified:

1. CVO creates proposals with readiness JSON containing olm_operator_lifecycle data for all 5 operators
2. The update-advisor skill analyzes readiness data and classifies findings per its decision policy
3. The update-advisor calls product-lifecycle to cross-check operators against the PLC API
4. plc_lookup.py olm-check correctly returns lifecycle data for cluster-logging and web-terminal, reports "unavailable" for compliance-operator, openshift-pipelines, and devworkspace-operator
5. plc_lookup.py products finds compliance-operator by product name even when olm-check can't match by package name

Cluster readiness summary (from proposal ota-4-21-5-to-4-21-16):

• 9/9 readiness checks passed in 2.56s
• 34 ClusterOperators healthy, 6 nodes ready, 3/3 etcd members
• 207 CRDs (0 version issues), 21 PDBs (0 blocking)
• OVNKubernetes, TLS Intermediate, no deprecated APIs
• 5 OLM operators detected with versions, channels, and install status

Ground truth verification

All expected values in evals were verified against the live PLC v2 API:

$ plc_lookup.py products "Red Hat OpenShift Container Platform" --ocp 4.21  →  4.21: supported
$ plc_lookup.py products "Red Hat OpenShift Container Platform" --ocp 4.14  →  4.14: extended
$ plc_lookup.py products "logging for Red Hat OpenShift" --ocp 4.21         →  6.5: supported, ocp_compatible=true
$ plc_lookup.py products "compliance operator"                              →  v1.9: supported
$ plc_lookup.py olm-check --ocp 4.21 --operators '[5 operators]'           →  2 found, 3 unavailable

🤖 Generated with Claude Code

[harche]

/cc @wking

[harche]

/hold improving evals with better data.

[harche]

Converting to draft, I need to make a few more changes before it is ready for the review.

[harche]

Converting to draft, I need to make a few more changes before it is ready for the review.

back to open.

[openshift-ci]

@harche: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/eval	0544f37	link	true	/test eval

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.