Update OLMv0 lifecycle enhancement to use ListPackageCustomSchemas gRPC endpoint#2013
Update OLMv0 lifecycle enhancement to use ListPackageCustomSchemas gRPC endpoint#2013perdasilva wants to merge 2 commits into
Conversation
Replace the dedicated lifecycle-controller/server approach with the ListPackageCustomSchemas gRPC endpoint on existing CatalogSource catalog pods. This eliminates two new downstream-only components by reusing the existing opm serve infrastructure. Changes: - Primary approach is now ListPackageCustomSchemas on catalog pods instead of dedicated lifecycle-controller and lifecycle-server - Lifecycle-controller/server moved to alternatives as a fallback - Console backend acts as a gRPC client to catalog pods directly - Document FNV64a content-addressed storage and cache digest handling - Add duplicate metadata handling (catalog pipeline prevents, Console logs error and shows "No data" as defense-in-depth) - Remove console-operator RBAC (no longer needed with gRPC endpoint) - Add open question for TP→GA validation of the new approach - Document risks: gRPC API surface, mixed opm versions, cache digest mismatch, deprecated SQLite backend returns Unimplemented Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
|
||
| * As a cluster administrator, I want lifecycle and compatibility information to be available in disconnected environments, so that I have the same operational visibility regardless of cluster connectivity. | ||
|
|
||
| * As an operator author, I want to include lifecycle metadata in my operator's catalog entry, so that my users have visibility into the support status of my operator versions. |
There was a problem hiding this comment.
nit: why don't we keep this? 🤔
There was a problem hiding this comment.
I think I removed to not cause confusion about who is adding the lifecycle metadata for this work. In our case, the lifecycle metadata is owned by another actor our of band of the operator authors (of course there's nothing stopping the operator author from doing so).
Co-authored-by: Francesco Giudici <fgiudici@foggy.day>
|
@perdasilva: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. |
2 participants
Summary
ListPackageCustomSchemasgRPC endpoint on existing CatalogSource catalog pods, eliminating two new downstream-only componentsListPackageCustomSchemasdirectly on catalog pods instead of proxying to a dedicated lifecycle-serverListPackageCustomSchemasimplementation details: FNV64a content-addressed storage, cache digest handling across opm versions, duplicate metadata handling, and graceful degradation for older opm versionsListPackageCustomSchemasapproach during Tech Preview before GA graduationTest plan
ListPackageCustomSchemasapproach🤖 Generated with Claude Code