feat: add Feast feature store integration

[Copilot]

Adds Feast (v0.59.0+) feature store integration to enable offline historical feature retrieval and online feature serving for ML workflows.

Changes

• Optional dependency: feast>=0.59.0 under [project.optional-dependencies]
• Minimal FeastClient wrapper (kubeflow/feast/api/feast_client.py):
  • Provides simplified initialization with repo_path or config parameters
  • Exposes feature_store property for direct access to the underlying Feast FeatureStore
  • Users access full Feast functionality through client.feature_store.*
• Integration tests (3 tests): Unit tests for initialization and ImportError handling + end-to-end test with SQLite/Parquet local setup
• Documentation: Usage examples and supported projects table update

Example

from kubeflow.feast import FeastClient

# Initialize client with simplified interface
client = FeastClient(repo_path="/path/to/feast/repo")

# Access full Feast functionality through feature_store property
features = client.feature_store.get_online_features(
    features=["feature_view:feature1", "feature_view:feature2"],
    entity_rows=[{"entity_id": 1}, {"entity_id": 2}],
)

# Materialize to online store
from datetime import datetime, timedelta
client.feature_store.materialize(
    start_date=datetime.now() - timedelta(days=7),
    end_date=datetime.now()
)

# List feature views
for fv in client.feature_store.list_feature_views():
    print(f"Feature view: {fv.name}")

Install with: pip install 'kubeflow[feast]'

Design Decision

This implementation uses a minimal wrapper approach that focuses on simplified initialization while providing full access to Feast's API through the feature_store property. This avoids unnecessary abstraction and allows users to leverage the complete Feast SDK functionality directly.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add Feast to Kubeflow SDK</issue_title>
<issue_description>### What you would like to be added?

Add Feast to Kubeflow SDK

Why is this needed?

For a complete AI/ML devx, Feast is needed for offline retrieval of historical datasets and for online serving of features/data. Incorporating the Feast SDK into the Kubeflow SDK is a great way to enable a smooth UX.

Love this feature?

Give it a 👍 We prioritize the features with most 👍</issue_description>

<agent_instructions>Please use feast>= 0.59.0 and test Feast with the simple local setup as an integration test.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Add Feast to Kubeflow SDK #239

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kramaranya for approval. For more information see the Kubernetes Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[franciscojavierarceo]

@copilot why are we implementing all of the feast Feature Store class methods? Why wouldn't the user just directly use the Feast SDK?

[Copilot]

You raise a good point. The current implementation does wrap many Feast methods without adding significant value beyond what users would get from using Feast directly.

Looking at the ModelRegistryClient pattern, the wrapper should provide value through:

1. Simplified, Kubeflow-aligned initialization
2. Integration with Kubeflow workflows
3. The store property already provides direct access to the underlying FeatureStore for advanced use cases

I can simplify this in a few ways:

Option 1: Minimal wrapper - Keep only essential initialization and provide the store property for full Feast access. Users who want all Feast features use client.store.*

Option 2: Remove wrapper entirely - Just document how to use Feast alongside Kubeflow SDK

Option 3: Keep current approach - The wrapper provides consistent API patterns across the Kubeflow SDK ecosystem, even if it's mostly pass-through

What's your preference? I'd lean toward Option 1 (minimal wrapper with store property access) as it balances convenience with avoiding unnecessary abstraction.

[franciscojavierarceo]

Yeah Option 1 feels right.

[franciscojavierarceo]

@copilot Option 1 feels right. Small nit it should probably be client.feature_store.*

[Copilot]

Done! Simplified to minimal wrapper approach with feature_store property in commit e78cee2.

Changes:

• Removed all pass-through methods (get_online_features, materialize, apply, list_* methods)
• Renamed store → feature_store property
• Updated tests and README to use client.feature_store.* pattern
• Reduced code from ~189 lines to ~103 lines

Users now access full Feast functionality through the property: client.feature_store.get_online_features(...), client.feature_store.materialize(...), etc.