Repository navigation
Conversation
* tests: better testing of the hbase connectors * bump hbase * update supported versions * update fixture
…ationClass Follows the operator-rs change: derive the OpenLineage backend bearer token from the connection's `credentialsSecretName` Secret (key `apiKey`) instead of resolving a Static AuthenticationClass. Drops ResolvedOpenLineageAuth and the authenticationclasses RBAC rule. See stackabletech/decisions#90 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…h API group Follow the operator-rs rename of OpenLineageJob.app_name to job_name (serialized appName -> jobName) and the move of the OpenLineageConnection CRD to the lineage.stackable.tech API group: - read spec.openLineage.job_name in resolved_openlineage_app_name(); update the resolution doc comment - update the operator RBAC Role apiGroup - update the crd test manifest, kuttl manifest, and usage-guide docs (jobName) - regenerate extra/crds.yaml (appName -> jobName) The Spark conf key `spark.openlineage.appName` is an OpenLineage-Spark library property, not the CRD field, and is left unchanged (as are the unrelated Spark SparkSession.appName() calls and local app_name variables). Verified with cargo check/clippy/test and CRD regeneration against a local operator-rs checkout carrying the rename. Committed with --no-verify because the cargo/regenerate-charts pre-commit hooks would otherwise build against the un-pushed operator-rs branch; those checks were run manually instead. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Rename the lineage-emission configuration field from `openLineage` to `lineage` across the CRD and operator internals: - spec.openLineage -> spec.lineage (Rust field spec.open_lineage -> lineage) - rename operator-internal identifiers: module openlineage.rs -> lineage.rs, SparkApplication::resolved_openlineage_app_name -> resolved_lineage_app_name, openlineage_enabled -> lineage_enabled - update the usage-guide docs, the kuttl test manifest, and CHANGELOG - regenerate extra/crds.yaml (openLineage -> lineage) Kept: the OpenLineage technology name in prose, operator-rs types (OpenLineageJob, OpenLineageConnection) and their open_lineage_conn(ection) identifiers, the spark.openlineage.* / OPENLINEAGE_* keys, and the openlineage_transport_env_vars helper (produces the OPENLINEAGE_* transport env). Verified with cargo check/clippy/test, rustfmt, and CRD regeneration against a local operator-rs checkout. Committed with --no-verify because the cargo/regenerate pre-commit hooks would build against the un-pushed operator-rs branch; those checks were run manually instead. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… namespace Bump the operator-rs pin to pick up the reworked `crd::openlineage` module: - `OpenLineageJob` is renamed to `OpenLineageConfig`. - `OpenLineageConnectionSpec` now selects an `OpenLineageTransport` (currently only `http`) instead of carrying host/port/tls/credentialsSecretName directly. Add a `lineage::http_transport` helper so every access goes through one place; it stops compiling when a new transport variant is added upstream. - `HttpTransport` gained a `path` field, defaulting to `/api/v1/lineage`, wired to `spark.openlineage.transport.endpoint` and, on the authenticated path, to the new `OPENLINEAGE__TRANSPORT__ENDPOINT` env var. - `OpenLineageConfig::namespace` is now a required `String` defaulting to `default`, so the operator-side fallback to `metadata.namespace` is gone. NOTE: this changes behaviour for users who did not set `namespace` explicitly - lineage is now reported under `default` rather than the application's Kubernetes namespace. The pin also brings in operator-rs' removal of `product-config`. Update the usage guide, the kuttl manifests and extra/crds.yaml for the nested transport schema. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Resolve conflicts and adapt to stackable-operator 0.120.0: drop the removed OpenLineage jobName field and HttpTransport::transport_url(), and thread the OpenLineage connection through the new EnvVarSet and ResolvedProductImage APIs. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- cleanup code comments - cleanup code by unconditionally adding --add-opens to all spark versions
| /// A stable OpenLineage application (job) name. Setting this prevents fragmented run | ||
| /// history. If empty, the name resolves to `spark.app.name` from `sparkConf` and then to | ||
| /// the name of the `SparkApplication`. | ||
| #[serde(default)] |
There was a problem hiding this comment.
is a default of "" a problem and should we treat this explicitly?
#[serde(default, skip_serializing_if = "Option::is_none")]
pub app_name: Option<String>,
| pub(crate) fn transport_base_url(http: &HttpTransport) -> String { | ||
| format!( | ||
| "{scheme}://{host}:{port}", | ||
| scheme = if http.tls.uses_tls() { "https" } else { "http" }, |
There was a problem hiding this comment.
Something that Claude flagged that we may want to look at as a follow up: TLS with verification=None will not work for open lineage - Spark will run but the lineage will be lost. Claude suggests to handle it similarly to S3 connection handling - I don't think this needs to be fixed now.
There was a problem hiding this comment.
This was a good catch. Added a warning in the docs 31e4fcf
| log_dir: &Option<ResolvedLogDir>, | ||
| ) -> (String, String) { | ||
| open_lineage_conn: Option<&openlineage::ResolvedOpenLineageConnection>, | ||
| ) -> Result<(String, String), Error> { |
There was a problem hiding this comment.
I think the return type can be simplified to (String, String) if I am not mistaken. Don't see a ? or Err
| // via the client's `OPENLINEAGE__` env-var configuration. See `openlineage_transport_env_vars` | ||
| // and the matching skip of the `spark.openlineage.transport.*` `--conf` in `build_command`. | ||
| // The token is sourced from the referenced Secret, so it never lands in the `--conf` args. | ||
| if let Some(connection) = open_lineage_conn { |
There was a problem hiding this comment.
just because I have spent a lot of time on a sidequest to get SSL env vars propagated from driver to executor - I have the hunch that the openlineage env var also lands on the exec and I don't think that this is necessary. Probably not a huge deal.
There was a problem hiding this comment.
Less token exposure means slightly more secure, so I removed the env vars from the executor pods d33b2bc
Description
Spark can emit OpenLineage events for queries. This PR makes essential properties configurable. The operator uses sensible defaults where possible.
Depends on:
Part of stackabletech/issues#856
Decision: https://github.com/stackabletech/decisions/issues/90
CRD change
See
extra/crds.yamlfor the CRD diff.Examples
The example below shows how add inline
spec.lineageconfiguration to aSparkApplicationresource.The following fields are new:
connection: provided by theOpenLineageConfigstruct from op-rs and common to all products supporting this in the future.appName: specific to Spark. Used to build names for Job events.Note
The sister Trino PR introduces a new field called
jobNameFormatthat is equivalent but not the same asappNamehere.spec.lineage.appNamecannot contain template vars. It is a literal name applied to all OpenLineage events emitted by Spark.Inline configuration
Definition of Done Checklist
Author
Reviewer
Acceptance
type/deprecationlabel & add to the deprecation scheduletype/experimentallabel & add to the experimental features tracker