Skip to content

[FSTORE-1903] Backwards compatibility and upgrade tests for Feature Logging - #651

Open
manu-sj wants to merge 3 commits into
logicalclocks:mainfrom
manu-sj:FSTORE-1903
Open

manu-sj wants to merge 3 commits into
logicalclocks:mainfrom
manu-sj:FSTORE-1903

Conversation

@manu-sj

@manu-sj manu-sj commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Summary

FSTORE-1871 combined the logging feature groups, renamed label columns to predicted_<label> and replaced hsml_model with model_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

  • Wording checked against the behaviour verified on a cluster: an old client may enable logging on a legacy feature view and keep logging, while enabling logging on a newly created feature view from an old client is unsupported.
  • The stated pre-4.6 limits match the markers asserted by the loadtest compatibility test.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DxdV8jEhUKSKssaLexdYSQ

manu-sj and others added 2 commits September 28, 2026 13:48
…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>

@javierdlrm javierdlrm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@javierdlrm

Copy link
Copy Markdown
Contributor

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>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants