Feast Namespace Registry

Overview

The Feast Namespace Registry is a feature that automatically creates and maintains a centralized ConfigMap containing information about all Feast feature store instances deployed by the operator. This enables dashboard applications and other tools to discover and connect to Feast instances across different namespaces.

Implementation Details

1. ConfigMap Creation: The operator creates a ConfigMap in the appropriate namespace:

   • OpenShift AI: redhat-ods-applications namespace (or DSCi configured namespace)
   • Kubernetes: feast-operator-system namespace

2. Access Control: A RoleBinding is created to allow system:authenticated users to read the ConfigMap

3. Automatic Registration & Cleanup: When a new feature store instance is created, it automatically registers its namespace and client configuration in the ConfigMap. When deleted, it automatically removes its entry from the ConfigMap

4. Data Structure: The ConfigMap contains a JSON structure with namespace names as keys and lists of client configuration names as values

ConfigMap Structure

The namespace registry ConfigMap (feast-configs-registry) contains the following data:

{
  "namespaces": {
    "namespace-1": ["client-config-1", "client-config-2"],
    "namespace-2": ["client-config-3"]
  }
}

Usage

The namespace registry is automatically deployed when any Feast feature store instance is created. No additional configuration is required.

For External Applications

External applications can discover Feast instances by:

1. Reading the ConfigMap from the appropriate namespace:
   bashCopy

   # For OpenShift
   kubectl get configmap feast-configs-registry -n redhat-ods-applications -o jsonpath='{.data.namespaces}'
   
   # For Kubernetes
   kubectl get configmap feast-configs-registry -n feast-operator-system -o jsonpath='{.data.namespaces}'
   

Lifecycle Management

The namespace registry automatically manages the lifecycle of feature store instances:

1. Creation: When a feature store is deployed, it registers itself in the ConfigMap
2. Updates: If a feature store is updated, its entry remains in the ConfigMap
3. Deletion: When a feature store is deleted, its entry is automatically removed from the ConfigMap
4. Namespace Cleanup: If all feature stores in a namespace are deleted, the namespace entry is also removed