Repository navigation
Conversation
8ae455d to
bc02eca
Compare
…ogging https://hopsworks.atlassian.net/browse/FSTORE-1903 FSTORE-1871 reworked feature logging around a single combined logging feature group, while feature views that enabled logging before the upgrade keep their frozen pre-1871 pair of feature groups. Running model deployments and batch services embed old Python clients that must keep logging against those legacy feature groups with zero downtime, and new clients must keep working against them too. Document the upgrade compatibility contract on the feature logging user guide: pre-upgrade feature views keep working for old and new clients alike, purging converts them to the combined layout, enabling logging on new feature views requires a 4.6 or later client, and positional log() calls written for the pre-4.6 signature keep working on pre-upgrade feature views with the keyword form as the migration target. Also correct the enablement section, which still described the pre-4.6 pair of logging feature groups. Signed-off-by: Manu Sathyarajan Joseph <manu.joseph@logicalclocks.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ogging https://hopsworks.atlassian.net/browse/FSTORE-1903 Pre-PR review fix for the FSTORE-1903 documentation: two sections of the feature logging guide still described the pre-4.6 layout. The materialize and delete sections described a pair of logs and the transformed argument as selecting one of them. They now state what the argument does on each layout: on the pre-4.6 pair delete_log() replaces the pair as a whole whichever slot is named, and on the combined layout there is a single log, so materialize_log(transformed=...) makes no difference and delete_log(transformed=True) does nothing. Signed-off-by: Manu Sathyarajan Joseph <manu.joseph@logicalclocks.com> Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
bc02eca to
2e117bf
Compare
javierdlrm
left a comment
There was a problem hiding this comment.
Cross-repo review for FSTORE-1903 (with hopsworks-ee#3334, hopsworks-api#1160, loadtest#1033). Every statement on the page matches the code: conversion on either selector, no-op on the combined layout, realtime by default after conversion (the 4.4 groups were stream groups), old-client positional detection, and unsupported logging on new views. One Should Fix inline: a restriction the SDK enforces that the page does not mention. The branch is 6 commits behind main but merges cleanly.
|
|
||
| Feature views that enabled logging before the upgrade keep their original pair of logging feature groups unchanged. | ||
| Model deployments and batch jobs that still run a pre-4.6 client keep logging to those feature views without any code change or downtime. | ||
| Clients from 4.6 onwards also keep working against them: predictions and the model identity are written into the original columns, and `feature_view.read_log(model_name=..., model_version=...)` filters on the original `hsml_model` column. |
There was a problem hiding this comment.
Should Fix. This covers the name+version filter, but on a pre-4.6 logging group read_log(model_name=…) alone and read_log(model_version=…) alone raise: the SDK refuses them because hsml_model holds <name>_<version> and a prefix match cannot express "any version" (_ is a wildcard and sibling names share the prefix). Worth one sentence here with that reason, per the content guide's rule that every restriction explains why.
|
Cross-repo note for FSTORE-1903: the release-line question for this set (backports to 4.6/4.7/4.8 and a 4.4/4.5 loadtest line for the upgrade leg) is raised on logicalclocks/hopsworks-ee#3334; this PR is part of the same set. |
…ogging https://hopsworks.atlassian.net/browse/FSTORE-1903 Address review round 1 on the feature logging guide. State that on feature views with the pre-4.6 logging groups, model_name and model_version must be passed together to read_log and log, and why a name-only filter cannot be expressed on hsml_model. Signed-off-by: Manu Sathyarajan Joseph <manu.joseph@logicalclocks.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Summary
FSTORE-1871 combined the logging feature groups, renamed label columns to
predicted_<label>and replacedhsml_modelwithmodel_name/model_version. Model deployments and batch services already running a pre-4.6 Hopsworks client must keep logging against an upgraded backend without any code change, and current clients must read and write the logging feature groups those old clients created.This repo documents the resulting behaviour for users: what a pre-4.6 client can and cannot do against an upgraded backend, and what happens to logging feature groups created before the upgrade, including the materialize and delete paths.
Test plan
🤖 Generated with Claude Code
https://claude.ai/code/session_01DxdV8jEhUKSKssaLexdYSQ