fix: report application URL at status.viz.url for the Data Manager#10
Merged
Merged
Conversation
The CRD's 'application-url-location: viz.url' annotation tells the Data
Manager to read the URL from status['viz']['url']. The create handler
(id="viz") returned {"viz": {"url": url}}, which kopf nests under
status.viz, placing the URL at status.viz.viz.url - one level too deep.
The Data Manager only looks at status.viz.url, so it never saw the URL
within its grace period.
Add a tested, pure build_status() builder that returns 'url' as a
top-level key (status.viz.url) and have the create handler use it.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The operator was not reporting the application URL back to the Data Manager (DM) within its grace period.
The CRD carries the annotation:
That value is a
status-relative dotted path, so the DM reads the URL fromstatus['viz']['url'].The
createhandler is registered withid="viz", which makes kopf nest the entire return value understatus.viz. The handler returned{"viz": {"url": url}, ...}, so the URL actually landed atstatus.viz.viz.url— one level too deep. The DM only looks atstatus.viz.url, found nothing, and never received the URL.(The sibling jupyter operator works because its id is
jupyter, it returns{"notebook": {"url": ...}}→status.jupyter.notebook.url, matching itsjupyter.notebook.urlannotation. The viz annotation is the shorterviz.url, so the return must not re-nest underviz.)Fix
build_status()builder that returnsurlas a top-level key, so kopf'sviznesting + top-levelurl=status.viz.url, matching the annotation. Its docstring documents the contract.createhandler to returnbuild_status(...)instead of the double-nested dict.Tests (TDD)
Added three tests in
tests/test_handlers.py(written first, confirmed failing, now passing):test_build_status_places_url_at_the_annotated_location— walks the literal annotation pathviz.urlagainst the kopf-nested status.test_build_status_does_not_double_nest_under_viz— regression guard against thestatus.viz.viz.urlbug.test_build_status_reports_instance_metadata— the remaining status fields are preserved.50 tests pass; black, mypy (strict) and pylint are clean.
Note
The
createhandler runs only on the create event, so any pre-existing CR with the old double-nested status won't be re-patched — the fix applies to instances created (or recreated) once this operator image is deployed.🤖 Generated with Claude Code