chore: Manifest and SHA update for RHOAI 3.5 release - #16

• config/manifests/feastoperator/crd/bases/feast.dev_featurestores.yaml#L855-L907 (this comment)
• config/manifests/feastoperator/crd/bases/feast.dev_featurestores.yaml#L7144-L7196

• config/manifests/feastoperator/default/related_image_fs_patch.yaml#L12-L12 (this comment)
• config/manifests/feastoperator/overlays/odh/params.env#L1-L2
• config/manifests/feastoperator/overlays/rhoai/params.env#L1-L2

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "## candidate file"
if [ -f config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml ]; then
  sed -n '1,90p' config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml
else
  echo "missing file"
fi

echo "## related feeds"
rg -n "transportUrl|transportEndpoint|openlineage|Lineage|featurestore" config/manifests/feastoperator -g '*.yaml' -g '*.yml' || true

echo "## repository manifests mentioning localhost:8088?8080 API"
rg -n "localhost:80(080|88)|/api/v1/lineage|v1/lineage|transportUrl|transportEndpoint" config/manifests/feastoperator || true

echo "## files with OpenLineage docs/versions"
rg -n "OpenLineage|openlineage|VERSION|feast.*version|feastoperator" . -g '!**/.git/**' -g '!vendor/**' | head -200

Repository: opendatahub-io/feast-module-operator

Length of output: 27888

🌐 Web query:

OpenLineage Python HTTPTransport join URL transportUrl transportEndpoint raw http.py

💡 Result:

In the OpenLineage Python client, the HttpTransport mechanism handles the construction of the final request URL by joining a base URL and an endpoint path [1][2]. When configuring HttpTransport, you provide a required url (the base URL) and an optional endpoint [1][3]. If the endpoint is not explicitly provided, it defaults to api/v1/lineage [1][4]. The client's implementation ensures the final target URL is formed by correctly appending the endpoint to the base URL (e.g., url + / + endpoint) [1][5]. Key technical aspects include: 1. Configuration: You define the transport via environment variables (OPENLINEAGE_URL, OPENLINEAGE_ENDPOINT) or a configuration dictionary passed to OpenLineageClient [1][6]. 2. URL Construction: Internally, the HttpTransport class manages these parameters. The url parameter serves as the base, and the endpoint is appended to it to determine the destination for POST requests [1][5]. 3. Implementation: In the source code (typically found in openlineage/client/transport/http.py), the HttpTransport class utilizes these configuration values to initialize the HTTP session and perform requests [2][5]. The recent refactoring of the Python HTTP transport (e.g., PR #3646) has consolidated header and session management to ensure consistency in how these requests are dispatched [7]. For further implementation details, you can review the official OpenLineage Python client repository, specifically the openlineage/client/transport/http.py module and its associated unit tests in test_http.py, which demonstrate the expected joining behavior [5][8].

Citations:

• 1: https://openlineage.io/docs/client/python/configuration/
• 2: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.40.0/client/python.md
• 3: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.45.0/client/python/configuration.md
• 4: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.44.1/client/python/configuration.md
• 5: https://github.com/OpenLineage/OpenLineage/blob/main/client/python/tests/test_http.py
• 6: https://openlineage.io/docs/client/python/usage/
• 7: refactor python HTTP transport OpenLineage/OpenLineage#3646
• 8: https://github.com/OpenLineage/OpenLineage/blob/main/client/python/src/openlineage/client/client.py

🌐 Web query:

OpenLineage Python client 0.9.0 client transport http.py URL join

💡 Result:

In the OpenLineage Python client version 0.9.0, the HTTP transport does not utilize a complex URL joiner; instead, it typically appends a default or user-configured endpoint path to the provided base URL [1][2]. By default, the OpenLineage HTTP transport appends the path /api/v1/lineage to the base URL provided in the configuration [3][2]. Historically, this endpoint was hardcoded, which led to issues when users needed to specify different paths [4]. While subsequent versions introduced an explicit endpoint configuration option to customize or override this behavior [4], in version 0.9.0, the core HTTP transport implementation essentially concatenates the configured base URL with the default endpoint [2]. Technical implementation details: 1. Base URL: The url parameter provided in the transport configuration (via yaml or environment variables) serves as the base for all HTTP requests [2]. 2. Default Endpoint: Unless specified otherwise, /api/v1/lineage is appended to the base URL [2]. 3. Concatenation: Developers working with the client often verify this behavior by checking the final constructed URL against the expected full path, such as http://backend:5000/api/v1/lineage [1]. If you are encountering issues with URL construction, ensure that your base URL does not contain a trailing slash that might conflict with the appended endpoint path, as standard string concatenation or simple URL joining methods may result in double slashes in the final request URL [1][2].

Citations:

• 1: https://github.com/OpenLineage/OpenLineage/blob/main/client/python/tests/test_http.py
• 2: https://pypi.org/project/openlineage-python/0.9.0/
• 3: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.40.0/client/python.md
• 4: airflow: OPENLINEAGE_URL path is hardcoded OpenLineage/OpenLineage#695

🌐 Web query:

OpenLineage Python client 0.8.0 client transport http.py URL join

💡 Result:

In the OpenLineage Python client, the HTTP transport is configured using a base URL and an optional endpoint [1][2]. The client handles the construction of the final request URL by appending the specified endpoint to the base URL [1][2]. While the implementation details in the http.py module have evolved (for example, via refactors to standardize session and header management [3]), the standard behavior for URL resolution involves combining the configured base URL with the endpoint path, which defaults to api/v1/lineage if not otherwise specified [2][4]. Users do not typically need to manually perform a URL join; rather, they provide the url and endpoint in the HttpConfig or via environment variables (OPENLINEAGE_URL and OPENLINEAGE_ENDPOINT), and the internal HttpTransport logic manages the request formation [1][2]. When using the client, ensuring the base URL does not conflict with the appended endpoint path (such as trailing slashes) is standard practice in Python's request handling, which the client's internal transport logic is designed to accommodate [2]. If you are investigating specific behavior in version 0.8.0, note that this version is significantly older than the current releases. Modern versions of the OpenLineage Python client utilize a more robust configuration factory, and if you are experiencing issues with URL joining, it is recommended to verify the OPENLINEAGE_URL and OPENLINEAGE_ENDPOINT environment variables or the HttpConfig dictionary provided to the HttpTransport class [2][5].

Citations:

• 1: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.40.0/client/python.md
• 2: https://openlineage.io/docs/client/python/configuration/
• 3: refactor python HTTP transport OpenLineage/OpenLineage#3646
• 4: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.45.0/client/python/configuration.md
• 5: https://github.com/OpenLineage/OpenLineage/blob/main/client/python/src/openlineage/client/client.py

🌐 Web query:

Feast 0.65.0 OpenLineage version

💡 Result:

Feast version 0.65.0, released on July 20, 2026, introduced significant native support for OpenLineage [1][2][3]. Key highlights regarding this integration include: - OpenLineage Consumer: Feast 0.65.0 added an OpenLineage Consumer, which allows the system to receive, store, and visualize cross-producer lineage [1][4][2]. - Native Integration: The release provides native integration enabling automatic lineage tracking for ML feature engineering workflows [5][6]. It captures events without requiring code changes, provided the integration is enabled in the feature_store.yaml configuration file [5][6]. - Automatic Event Emission: The integration automatically emits OpenLineage events for key operations, specifically during feast apply (when registering feature definitions) and feast materialize (when populating the online store) [5][6][7]. - Configuration: To use this feature, users must enable it in their feature_store.yaml [5][6]. It is an optional dependency that can be installed via pip install feast[openlineage] [6][7]. This release represents a major update to Feast's lineage capabilities, shifting from simply emitting lineage events to also having the ability to consume and visualize them [1][2].

Citations:

• 1: https://github.com/feast-dev/feast/releases/tag/v0.65.0
• 2: https://github.com/feast-dev/feast/blob/master/CHANGELOG.md
• 3: https://pypi.org/project/feast/
• 4: feast-dev/feast@v0.64.0...v0.65.0
• 5: https://feast.dev/blog/feast-openlineage-integration/
• 6: https://docs.feast.dev/reference/openlineage
• 7: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.48.0/integrations/feast.md

🌐 Web query:

site:github.com/feast-dev/feast requirements.txt openlineage-python 0.65.0

💡 Result:

As of July 29, 2026, there is no standalone Python package named openlineage-python version 0.65.0. The version 0.65.0 mentioned in your query refers to a recent release of the Feast feature store project (feast-dev/feast), released on July 20, 2026 [1]. In the context of the Feast project, the dependency on openlineage-python is managed within the project's pyproject.toml file, which specifies a requirement of openlineage-python>=1.40.0 [2][3]. The Feast project includes openlineage-python as a dependency for its OpenLineage integration features [4][5][6]. If you are attempting to configure or manage requirements for a Python environment using these tools, you should reference the official Feast documentation or pyproject.toml for compatible versions, rather than seeking a version of openlineage-python that aligns with the Feast release number [2][3].

Citations:

• 1: https://github.com/feast-dev/feast/releases/tag/v0.65.0
• 2: https://github.com/feast-dev/feast/blob/master/pyproject.toml
• 3: https://github.com/feast-dev/feast/blob/1e1f5d94/pyproject.toml
• 4: feat: Add OpenLineage Consumer to Feast - receive, store, and visualize cross-producer lineage feast-dev/feast#6549
• 5: feast-dev/feast@df70d8d
• 6: feat: Added support for OpenLineage integration feast-dev/feast#5884

🌐 Web query:

site:github.com/OpenLineage/OpenLineage client/python http.py join_url transportUrl transportEndpoint

💡 Result:

In the context of OpenLineage and related integrations, transportUrl and transportEndpoint are configuration parameters used to define the destination for lineage metadata events [1]. Specifically, transportUrl typically refers to the base URL of an OpenLineage-compatible server (such as Marquez), while transportEndpoint specifies the relative path or API endpoint to which the lineage events should be sent [1]. These parameters are often defined in configuration files (e.g., YAML) for various integrations, such as Feast, to enable HTTP transport for event emission [1]. The reference to join_url and http.py in a Python client context generally relates to internal utility functions used for constructing valid HTTP request URLs by joining a base URL with specific path components. While these are common patterns in networking and API client implementations, they are fundamental mechanisms for correctly formatting the destination addresses composed of transportUrl and transportEndpoint [2]. For example, a typical configuration setup for these values would look like this [1]: transportType: http transportUrl: "http://example-server.com:5000" transportEndpoint: "api/v1/lineage" The Python client or relevant integration logic would then use a utility (often named join_url or similar) to ensure the final request URL is correctly formed by combining these components [2].

Citations:

• 1: https://github.com/feast-dev/feast/blob/stable/infra/feast-operator/config/samples/v1_featurestore_materialization_openlineage.yaml
• 2: https://github.com/Tracer-Cloud/opensre/blob/main/integrations/jenkins/__init__.py

🌐 Web query:

http://localhost:8080/api http://localhost:8080 v1/lineage uri join Python

💡 Result:

The URI structure http://localhost:8080/api/v1/lineage is a common pattern for interacting with data lineage APIs in various data catalog and orchestration systems [1][2]. Because localhost:8080 is a default development port, this specific path appears in the documentation for several different projects, including EdgeQuake [3], Marquez [4], Feast [1], and other platforms using OpenLineage [1]. To interact with these endpoints using Python, you should generally avoid raw HTTP requests if an official SDK is available, as these provide structured objects instead of raw JSON [3][4]. If you are using a library like requests to manually query such an API, you can use the following pattern: import requests base_url = "http://localhost:8080/api/v1" lineage_endpoint = f"{base_url}/lineage" # Example: Fetching lineage for a specific entity or document # Note: Check the specific API documentation for required parameters like node_id or workspace_id params = {"node_id": "your-entity-id"} response = requests.get(lineage_endpoint, params=params) if response.status_code == 200: data = response.json print(data) else: print(f"Failed to fetch lineage: {response.status_code}") Key considerations for these APIs: 1. Path Variations: While /api/v1/lineage is common, many systems use sub-paths like /api/v1/lineage/documents/{id} or /api/v1/lineage/entities/{name} depending on the specific resource you are querying [3][5][2]. 2. Authentication: Many production or containerized instances require headers such as Authorization: Bearer <token> or workspace-specific headers (e.g., X-Workspace-ID) [6][5][7]. 3. SDKs: Always check if the specific tool you are using (e.g., OpenMetadata, Marquez) provides a native Python client, as these usually handle URL construction and authentication automatically [3][8][4].

Citations:

• 1: https://docs.feast.dev/master/reference/openlineage
• 2: https://docs.matih.ai/10-data-catalog/lineage/
• 3: https://edgequake.com/docs/api-reference/lineage-endpoints/
• 4: feat: add get_lineage() to Python client MarquezProject/marquez#3104
• 5: https://docs.open-metadata.org/v1.12.x/api-reference/lineage/get
• 6: https://github.com/raphaelmansuy/edgequake/blob/HEAD/docs/api-reference/extended-api.md
• 7: https://docs.open-metadata.org/v1.13.x/api-reference/lineage/add
• 8: https://docs.getcollate.io/api-reference/lineage/get

🌐 Web query:

"join_url" "http://localhost:8080/api" "v1/lineage"

💡 Result:

The URL http://localhost:8080/api/v1/lineage is a local development endpoint typically associated with data lineage management APIs [1]. Based on industry documentation, endpoints structured as /api/v1/lineage are used in data governance and metadata management platforms—most notably OpenMetadata—to programmatically add, update, or retrieve information about data dependencies (such as relationships between tables, dashboards, and pipelines) [1][2]. When interacting with this specific endpoint in a development environment: 1. Local context: The http://localhost:8080 base indicates a service running on your local machine, commonly configured in tools like OpenMetadata or similar containerized applications [3][4][2]. 2. Usage: This endpoint typically accepts PUT or GET requests to manage lineage graphs [1][2]. For example, in OpenMetadata, a PUT request to {base_url}/api/v1/lineage is used to define an edge between two entities (e.g., a source table and a target table) [1]. 3. Security: If you are accessing this on your local machine, ensure you have the correct authentication headers (such as a Bearer token) if the service is configured with security enabled [1][2]. If you are encountering connection issues with this URL, ensure that the corresponding service is active and listening on port 8080 [3][4]. If you are working with a different API that uses a parameter named join_url, note that this parameter is common in video conferencing integrations (e.g., Zoom, Microsoft Teams) for joining meetings, and is distinct from the /v1/lineage path mentioned [5][6][7].

Citations:

• 1: https://openmetadata.mintlify.app/v1.12.x/api-reference/lineage/add
• 2: https://docs.open-metadata.org/v1.13.x/api-reference/lineage/get
• 3: https://stackoverflow.com/questions/77011585/get-http-localhost8080-api-neterr-connection-refused
• 4: Error occuper while trying to proxy to : http://localhost:8080/api chimurai/http-proxy-middleware#181
• 5: https://devforum.zoom.us/t/join-meeting-api/47243
• 6: https://docs.cronofy.com/developers/api/meeting-agents/schedule/
• 7: https://www.rev.com/api/meetingspost

🌐 Web query:

urllib.parse urljoin "http://localhost:8080/api" "v1/lineage"

💡 Result:

Using urllib.parse.urljoin('http://localhost:8080/api', 'v1/lineage') will result in the URL 'http://localhost:8080/v1/lineage' [1][2]. This occurs because urljoin treats the base URL 'http://localhost:8080/api' as if it refers to a file or resource at the end of a directory structure [2][3]. When joining it with a relative path that does not start with a slash, the function removes the last segment of the base path (everything after the final '/') before appending the new component [2][4][5]. To obtain the expected path 'http://localhost:8080/api/v1/lineage', you should ensure the base URL ends with a trailing slash [2][3][6]. Example: from urllib.parse import urljoin print(urljoin('http://localhost:8080/api/', 'v1/lineage')) # Output: 'http://localhost:8080/api/v1/lineage' [2][3]

Citations:

• 1: https://docs.python.org/3/library/urllib.parse.html
• 2: https://stackoverflow.com/questions/10893374/python-confusions-with-urljoin
• 3: https://www.daniweb.com/programming/software-development/threads/492472/what-is-the-usage-of-urljoin
• 4: https://www.oreilly.com/library/view/python-in-a/0596001886/re767.html
• 5: https://pymotw.com/3/urllib.parse/index.html
• 6: https://discuss.python.org/t/urllib-join-behavior/86423

🌐 Web query:

site:github.com/OpenLineage/OpenLineage "def join_url" "class HttpTransport" client/python src/openlineage/client/transport/http.py

💡 Result:

There is no join_url method defined in the HttpTransport class within the OpenLineage Python client's client/python/src/openlineage/client/transport/http.py file. The OpenLineage Python client handles URL construction and endpoint management primarily through the HttpConfig configuration object, which allows users to specify both a base url and a specific endpoint (or path) [1][2][3]. Historically, the OpenLineage Python client automatically appended a default path (e.g., /api/v1/lineage) to the configured OPENLINEAGE_URL [2]. To address limitations where this hardcoded path was not desired, the client was updated to allow explicit configuration of the endpoint via HttpConfig [4]. If you are looking for how the client manages URLs, it uses standard library utilities (such as urllib.parse) to join or manipulate paths when building request URLs [5][6]. Recent refactoring of the Python HTTP transport has centralized session management and header configuration, but it does not implement a custom join_url utility method within the HttpTransport class itself [3][7].

Citations:

• 1: https://github.com/OpenLineage/OpenLineage/blob/main/client/python/tests/test_http.py
• 2: airflow: OPENLINEAGE_URL path is hardcoded OpenLineage/OpenLineage#695
• 3: refactor python HTTP transport OpenLineage/OpenLineage#3646
• 4: Allow setting client's endpoint via environment variable OpenLineage/OpenLineage#2151
• 5: fix(great-expectations): preserve datasource url ports OpenLineage/OpenLineage#4679
• 6: Attempt to fix unquoted [ and ] in snowflake URIs. OpenLineage/OpenLineage#1883
• 7: [Python] Reuse requests.Session() in sync HttpTransport OpenLineage/OpenLineage#3843

🏁 Script executed:

#!/bin/bash
set -euo pipefail

python3 - <<'PY'
from urllib.parse import urljoin

cases = [
    ("http://localhost:8080/api", "v1/lineage"),
    ("http://localhost:8080/api/", "v1/lineage"),
    ("http://localhost:8080", "api/v1/lineage"),
    ("http://marquez.feast.svc.cluster.local:5000", "api/v1/lineage"),
]
for base, endpoint in cases:
    print(f"{base!r} + {endpoint!r} = {urljoin(base, endpoint)!r}")
PY

Repository: opendatahub-io/feast-module-operator

Length of output: 551

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

🏁 Script executed:

#!/bin/bash
set -euopipefail

echo "Files:"
fd -a 'v1_featurestore_openlineage_consumer\.yaml|openlineage|feastoperator|consumer.yaml' . | sed 's#^\./##' | head -200

echo
echo "Target file excerpt:"
cat -n config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,120p'

echo
echo "Search secret/object references:"
rg -n "openlineage-(producer|consumer)-secret|transportUrl|transportEndpoint|apiKeySecretRef|Authorization|X-API-Key|http.py|Producer|Consumer" config manifests -S || true

echo
echo "Diff stat/summary:"
git diff --stat || true
git diff -- config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,220p' || true

Repository: opendatahub-io/feast-module-operator

Length of output: 827

🏁 Script executed:

#!/bin/bash
set -euopipefail

echo "Target file excerpt:"
cat -n config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,140p'

echo
echo "Search secret/object references:"
rg -n "openlineage-(producer|consumer)-secret|transportUrl|transportEndpoint|apiKeySecretRef|Authorization|X-API-Key|http.py|Producer|Consumer" config manifests -S || true

echo
echo "Diff stat:"
git diff --stat || true
echo
echo "Target diff excerpt:"
git diff -- config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,260p' || true

Repository: opendatahub-io/feast-module-operator

Length of output: 827

🏁 Script executed:

#!/bin/bash
set -e

echo "Workdir:"
pwd || true
echo
echo "Target file excerpt:"
if [ -f config/_manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml ]; then
  cat -n config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,160p'
elif [ -f config/_manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml ]; then
  cat -n config/_manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,160p'
else
  fd -a 'v1_featurestore_openlineage_consumer\.yaml' . | sed -n '1,40p'
fi

echo
echo "Search secret/object references:"
rg -n "openlineage-(producer|consumer)-secret|transportUrl|transportEndpoint|apiKeySecretRef|Authorization|X-API-Key|http.py|Producer|Consumer" config manifests -S || true

echo
echo "Diff stat:"
git diff --stat || true
if [ -f config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml ]; then
  git diff -- config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,260p' || true
elif [ -f config/_manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml ]; then
  git diff -- config/_manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,260p' || true
fi

Repository: opendatahub-io/feast-module-operator

Length of output: 3989

🏁 Script executed:

#!/bin/bash
set -e

echo "Target sample:"
cat -n config/manifests/feastoperator/samples/v1_featurestore_openlineage_consumer.yaml | sed -n '1,90p'

echo
echo "CRD excerpts around producer/consumer validation:"
for line in 835 850 860 915 930 7125 7140 7150 7200 7220; do
  echo "--- lines $((line-8)) to $((line+8))"
  sed -n "$((line-8)),$((line+8))p" config/manifests/feastoperator/crd/bases/feast.dev_featurestores.yaml | cat -n
done

echo
echo "Find Feast version references:"
rg -n "Feast|0\.65\.0|openlineage|OpenLineage|FeastAdapter|FeatureStore|materialization" README.md pyproject.toml setup.cfg setup.py config manifests -S || true

echo
echo "Search implementation references to producer/consumer/OpenLineage auth headers:"
rg -n "openlineage|OpenLineage|X-API-Key|Authorization|Bearer|apiKey|apiKeySecretRef|FeastAdapter|featurestore.*(producer|consumer)|producer|consumer" . -g '!config/manifests/feastoperator/crd/bases/feast.dev_featurestores.yaml' -S | rg -n "openlineage|X-API-Key|Authorization|Bearer|apiKey|api_key|FeastAdapter|producer|consumer" | sed -n '1,240p' || true

Repository: opendatahub-io/feast-module-operator

Length of output: 46243

🌐 Web query:

OpenLineage Python HTTPTransport HTTP header Authorization Bearer X-API-Key feast 0.65.0

💡 Result:

In Feast 0.65.0, the OpenLineage integration is configured within the feature_store.yaml file [1][2]. To use an Authorization Bearer token with the OpenLineage HTTP transport, you should leverage the built-in authentication support rather than attempting to pass an "X-API-Key" header manually [3][4]. The OpenLineage Python client supports api_key authentication directly, which automatically constructs the Authorization: Bearer <token> header [3][5]. 1. Configuration in feature_store.yaml: You can configure the authentication in your feature_store.yaml under the openlineage section [1][2]. While the standard Feast documentation lists api_key as a top-level option [1][2], the underlying OpenLineage Python client (which Feast uses) accepts an auth configuration block for more complex setups [3][4]. If your environment requires it, you can provide the API key as follows: openlineage: enabled: true transport_type: http transport_url: http://your-backend-url # The api_key option here is mapped to the OpenLineage client's auth configuration api_key: your_bearer_token 2. Using Custom Headers (if required): If you specifically need to pass a header named "X-API-Key" (rather than the standard Authorization header), the OpenLineage Python client supports custom_headers [5][6][7]. Note that this is typically done via the OpenLineage Python client's HttpConfig [5][6]. If you are configuring the transport via environment variables, you can set custom headers using OPENLINEAGETRANSPORTCUSTOM_HEADERS (e.g., as a JSON string) or through the HttpConfig object if you are initializing the client programmatically [3][5][6]. Summary for Feast 0.65.0: - Standard Bearer Auth: Use the api_key configuration option in feature_store.yaml [1][2]. The OpenLineage client handles the conversion to Authorization: Bearer <key> [5]. - Custom Headers: If you must use a header literally named X-API-Key, you would need to configure the custom_headers attribute of the OpenLineage HttpConfig [5][6]. Feast 0.65.0 introduced significant updates, including the ability for Feast to act as an OpenLineage consumer, but the producer-side HTTP transport configuration remains consistent with the standard OpenLineage Python client [8][9][10][2].

Citations:

• 1: https://docs.feast.dev/reference/openlineage
• 2: https://docs.feast.dev/master/reference/openlineage
• 3: https://openlineage.io/docs/client/python/configuration/
• 4: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.45.0/client/python/configuration.md
• 5: https://github.com/OpenLineage/OpenLineage/blob/main/client/python/tests/test_http.py
• 6: Python: allow custom headers in HTTP transport OpenLineage/OpenLineage#3116
• 7: https://github.com/OpenLineage/openlineage-site/blob/main/versioned_docs/version-1.44.1/client/python/configuration.md
• 8: https://github.com/feast-dev/feast/releases/tag/v0.65.0
• 9: feast-dev/feast@v0.64.0...v0.65.0
• 10: feat: Add OpenLineage Consumer to Feast - receive, store, and visualize cross-producer lineage feast-dev/feast#6549

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

verify_sha() {
  local repo="$1"
  local sha="$2"
  local tmp_dir
  tmp_dir="$(mktemp -d)"
  trap 'rm -rf -- "$tmp_dir"' RETURN

  git -C "$tmp_dir" init -q
  git -C "$tmp_dir" remote add origin "$repo"
  git -C "$tmp_dir" fetch --depth 1 -q origin "$sha"
  test "$(git -C "$tmp_dir" rev-parse FETCH_HEAD)" = "$sha"
}

verify_sha \
  "https://github.com/opendatahub-io/feast" \
  "863b09f490926aec0df1b92d34d7acd8b26f2dde"

verify_sha \
  "https://github.com/red-hat-data-services/feast" \
  "90e6fe62d917887a17f0fe8a2bf489d5723777db"

Repository: opendatahub-io/feast-module-operator

Length of output: 174

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

# Inspect the script and local RHOAI manifests without executing repository code.
printf '--- get-manifests.sh lines 1-45 ---\n'
sed -n '1,45p' hack/scripts/get-manifests.sh
printf '\n--- tracked files matching feast-operator/config (RHOAI/repo) ---\n'
git ls-files | rg '(^|/)(feast|rhoai|3\.5|RHOAI|RHOAI)' | sed -n '1,120p'
printf '\n--- path count ---\n'
git ls-files | rg '(^|/)infra/feast-operator/config' | wc -l
printf '\n--- sample manifest headers if present ---\n'
git ls-files | rg '(^|/)infra/feast-operator/config' | head -20 | xargs -r -n1 sh -c 'echo "--- $0"; sed -n "1,40p" "$0"' 2>/dev/null || true

Repository: opendatahub-io/feast-module-operator

Length of output: 265

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

# Inspect the script and local RHOAI manifests without executing repository code.
printf '%s\n' '--- get-manifests.sh lines 1-45 ---'
sed -n '1,45p' hack/scripts/get-manifests.sh
printf '%s\n' '--- tracked files matching feast-operator/config ---'
git ls-files | rg '(^|/)(feast|rhoai|3\.5|RHOAI|RHOAI)\' || true
printf '%s\n' '\n--- tracked infra/feast-operator/config files ---'
git ls-files | rg '(^|/)infra/feast-operator/config/' || true
printf '%s\n' '\n--- path count ---'
git ls-files | rg '(^|/)infra/feast-operator/config' | wc -l
printf '%s\n' '\n--- sample manifest headers if present ---'
git ls-files | rg '(^|/)infra/feast-operator/config' | head -20 | xargs -r -n1 sh -c 'echo "--- $0"; sed -n "1,20p" "$0"' 2>/dev/null || true

Repository: opendatahub-io/feast-module-operator

Length of output: 1939