Skip to content

Commit b657e1e

Browse files
mich-elle-lunamich-elle-luna
committed
Add Feature Form operation documentation
1 parent 1ed530b commit b657e1e

3 files changed

Lines changed: 299 additions & 0 deletions

File tree

‎content/operate/featureform/_index.md‎

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
---
2+
Title: Redis Feature Form
3+
alwaysopen: false
4+
categories:
5+
- docs
6+
- operate
7+
- featureform
8+
description: Deploy and operate Feature Form on Kubernetes.
9+
linkTitle: Redis Feature Form
10+
weight: 50
11+
bannerText: Feature Form is currently in preview and subject to change. To request access to the Feature Form Docker image, contact your Redis account team.
12+
bannerChildren: true
13+
---
14+
15+
Feature Form runs as a Kubernetes-based platform for feature engineering and online feature serving. Use this section to prepare your environment, choose a deployment method, install Feature Form, and verify that the platform is ready for application teams.
16+
17+
These docs are cloud-neutral in framing. Where Terraform examples are useful, request them from your Redis account team.
18+
19+
Use this section to decide how you want to install Feature Form before you create workspaces or register providers.
20+
21+
## Deployment model
22+
23+
The Helm chart deploys:
24+
25+
- one shared API server deployment that exposes both REST and gRPC
26+
- separate services for REST and gRPC
27+
- an optional dashboard
28+
- optional addons for Postgres state, provider infrastructure, and observability
29+
30+
Authentication is required. Standard installs need OIDC configuration.
31+
32+
## State-backend choices
33+
34+
- External PostgreSQL: the durable default for shared deployments
35+
- Bundled state PostgreSQL: useful for self-contained evaluation or test installs
36+
- Memory state: local or CI only, not durable
37+
38+
With memory state, gRPC and REST do not share one durable graph. Keep that in mind when troubleshooting “missing” workspaces or resources.
39+
40+
## Exposure choices
41+
42+
- internal-only services
43+
- service-specific ingresses
44+
- unified ingress
45+
- direct `LoadBalancer` services
46+
47+
Do not combine unified ingress with service-specific ingress settings.
48+
49+
## Helm profiles
50+
51+
- base chart
52+
- `profiles/memory.yaml`
53+
- `profiles/provider-stack.yaml`
54+
- `profiles/observability-postgres.yaml`
55+
- `profiles/provider-observability.yaml`

‎content/operate/featureform/auth.md‎

Lines changed: 110 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,110 @@
1+
---
2+
Title: Authentication and RBAC
3+
alwaysopen: false
4+
categories:
5+
- docs
6+
- operate
7+
- featureform
8+
description: Manage Feature Form auth and RBAC
9+
linkTitle: Authentication and RBAC
10+
weight: 70
11+
bannerText: Feature Form is currently in preview and subject to change. To request access to the Feature Form Docker image, contact your Redis account team.
12+
bannerChildren: true
13+
---
14+
Feature Form separates deployment-wide administration from workspace-scoped actions. A workspace is the isolation boundary, but membership and permissions are managed separately through RBAC bindings.
15+
16+
## Built-in roles
17+
18+
- `global_admin` for deployment-wide administration and workspace creation
19+
- `workspace_admin` for workspace setup, membership, apply, and audit
20+
- `operator` for operational workflows
21+
- `viewer` for read-only workspace visibility
22+
- `model` for constrained reads of feature views and training sets
23+
24+
## Typical handoff
25+
26+
1. A global admin creates the workspace.
27+
2. The global admin grants `workspace_admin` to the intended principal.
28+
3. That principal verifies access before registering providers or applying resources.
29+
30+
## Scope model
31+
32+
- Global scope controls deployment-wide actions.
33+
- Workspace scope controls providers, secret providers, apply, graph, and audit inside one workspace.
34+
- Resource-constrained scope is used for limited serving or training-set access.
35+
36+
## Create a workspace and grant access
37+
38+
Use this flow when a global admin is creating a new workspace and handing it off to the team that will manage it.
39+
40+
### 1. Create the workspace
41+
42+
```bash
43+
ff workspace create demo-workspace \
44+
--description "Workspace for the feature workflow docs path"
45+
```
46+
47+
### 2. Verify it exists
48+
49+
```bash
50+
ff workspace get --name demo-workspace
51+
ff workspace list
52+
```
53+
54+
Capture the workspace ID from the result for later RBAC commands.
55+
56+
### 3. Grant workspace-admin access
57+
58+
```bash
59+
ff rbac grant workspace_admin \
60+
--workspace <workspace-id> \
61+
--user alice@example.com
62+
```
63+
64+
You can also bind a group or service account instead of a user.
65+
66+
### 4. Verify the binding
67+
68+
```bash
69+
ff rbac list --workspace <workspace-id>
70+
ff rbac subjects --workspace <workspace-id>
71+
```
72+
73+
### Notes
74+
75+
- Creating the workspace does not automatically grant workspace membership to other principals.
76+
- New workspaces create a built-in `env` secret provider, but it is still workspace-scoped.
77+
- In-memory state can make gRPC and REST behave like separate state domains. Use durable PostgreSQL-backed state for shared environments.
78+
79+
## Join an existing workspace
80+
81+
Use this page when a workspace already exists and you need to confirm that the intended principal can proceed with setup, apply, or serving.
82+
83+
### 1. Verify identity
84+
85+
```bash
86+
ff auth whoami
87+
ff rbac whoami
88+
```
89+
90+
### 2. Confirm the workspace is visible
91+
92+
```bash
93+
ff workspace list
94+
ff workspace get --name demo-workspace
95+
```
96+
97+
### 3. Confirm the effective binding
98+
99+
```bash
100+
ff rbac list --workspace <workspace-id>
101+
```
102+
103+
You should see the expected user, group, or service-account binding for that workspace.
104+
105+
### Common failures
106+
107+
- `permission denied` on provider or apply commands usually means missing workspace write access.
108+
- `workspace not found` usually means the wrong deployment, wrong transport, or wrong workspace name.
109+
- Missing resources after apply can indicate transport or state-backend mismatch in non-durable environments.
110+

‎content/operate/featureform/deploy.md‎

Lines changed: 134 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,134 @@
1+
---
2+
Title: Deploy
3+
alwaysopen: false
4+
categories:
5+
- docs
6+
- operate
7+
- featureform
8+
description: Deploy and operate Feature Form on Kubernetes.
9+
linkTitle: Deploy
10+
weight: 60
11+
bannerText: Feature Form is currently in preview and subject to change. To request access to the Feature Form Docker image, contact your Redis account team.
12+
bannerChildren: true
13+
---
14+
15+
Use this guide to install Feature Form with the Helm chart and verify that the core services are healthy.
16+
17+
## Install
18+
19+
The default documented path is OIDC-enabled auth plus durable PostgreSQL-backed state.
20+
21+
### Prerequisites
22+
23+
- Kubernetes 1.27+
24+
- Helm 3.14+
25+
- an OIDC issuer URL and client ID
26+
- a PostgreSQL connection path or existing secret
27+
28+
### 1. Choose auth and state values
29+
30+
Pick one PostgreSQL-backed state path before installation:
31+
32+
- `postgres.url`
33+
- `postgres.secretName`
34+
- `addons.statePostgres.enabled=true`
35+
36+
External PostgreSQL is the documented durable default.
37+
38+
### 2. Pick the base chart or a profile
39+
40+
- Base chart for environments where provider infrastructure already exists
41+
- `profiles/memory.yaml` for local or test-only installs
42+
- `profiles/provider-stack.yaml` for bundled providers
43+
- `profiles/observability-postgres.yaml` for observability
44+
- `profiles/provider-observability.yaml` for both
45+
46+
### 3. Install with Helm
47+
48+
```bash
49+
helm upgrade --install featureform charts/featureform \
50+
--set postgres.url=postgres://featureform:featureform@my-postgres:5432/featureform?sslmode=disable \
51+
--set auth.oidcIssuerURL=https://idp.example.com/realms/featureform \
52+
--set auth.oidcClientID=featureform-api \
53+
--set rest.ingress.enabled=true \
54+
--set rest.ingress.className=nginx \
55+
--set rest.ingress.hosts[0].host=api.example.com \
56+
--set rest.ingress.hosts[0].paths[0].path=/ \
57+
--set rest.ingress.hosts[0].paths[0].pathType=Prefix
58+
```
59+
60+
### 4. Validate pods and services
61+
62+
```bash
63+
kubectl get pods -n <namespace>
64+
kubectl get svc -n <namespace>
65+
kubectl describe deployment featureform-featureform-server -n <namespace>
66+
```
67+
68+
Look for a healthy shared API deployment, both REST and gRPC services, and completed migrations when PostgreSQL state is enabled.
69+
70+
### 5. Record the endpoints
71+
72+
Capture the URLs or hosts your teams will need:
73+
74+
- REST API endpoint
75+
- gRPC endpoint
76+
- dashboard URL if enabled
77+
- Grafana URL if enabled
78+
79+
### High-risk confusion points
80+
81+
- One shared server deployment exposes both REST and gRPC; they are not separate deployments.
82+
- `auth.enabled=false` is not supported.
83+
- `stateBackend=memory` is not durable.
84+
- The dashboard needs more than `dashboard.enabled=true`; it also needs correct auth and API URL settings.
85+
86+
## Configure external access
87+
88+
Use this section after installation to publish the right Feature Form endpoints for users, automation, and optional UI access.
89+
90+
### REST ingress example
91+
92+
```bash
93+
helm upgrade --install featureform charts/featureform \
94+
--set postgres.url=postgres://featureform:featureform@my-postgres:5432/featureform?sslmode=disable \
95+
--set auth.oidcIssuerURL=https://idp.example.com/realms/featureform \
96+
--set auth.oidcClientID=featureform-api \
97+
--set rest.ingress.enabled=true \
98+
--set rest.ingress.className=nginx \
99+
--set rest.ingress.hosts[0].host=api.example.com \
100+
--set rest.ingress.hosts[0].paths[0].path=/ \
101+
--set rest.ingress.hosts[0].paths[0].pathType=Prefix
102+
```
103+
104+
### gRPC exposure guidance
105+
106+
Use `grpc.ingress.*` only with an ingress controller that supports gRPC backends. If ingress is not a fit, use `grpc.service.type=LoadBalancer`.
107+
108+
### Dashboard requirements
109+
110+
A working dashboard path needs all of the following:
111+
112+
- `dashboard.enabled=true`
113+
- a resolvable public API URL
114+
- dashboard auth secrets
115+
- a resolvable auth URL
116+
117+
### Unified ingress
118+
119+
Unified ingress publishes one host with chart-managed paths for API, dashboard, and optionally Grafana. Do not combine it with service-specific ingress settings.
120+
121+
### Direct load balancers
122+
123+
If your platform prefers direct external services, expose:
124+
125+
- `rest.service.type=LoadBalancer`
126+
- `grpc.service.type=LoadBalancer`
127+
- `dashboard.service.type=LoadBalancer`
128+
129+
### Common validation failures
130+
131+
- missing ingress hosts
132+
- unified ingress mixed with service-specific ingresses
133+
- dashboard enabled without API URL or auth secrets
134+
- Grafana ingress configured without the observability stack enabled

0 commit comments

Comments
 (0)