Skip to content

Conversation

@adwk67
Copy link
Member

@adwk67 adwk67 commented Feb 5, 2026

Description

Fixes #64
Decision: https://github.com/stackabletech/decisions/issues/72

Notes for reviewers

  • This is large PR although most of the files that have been changed are due to tests and docs: the main changes are in database.rs, queue.rs and connection.rs.
  • We don't want the operator to have to read the secrets, and so the connection code (which will eventually be moved to the framework) returns a connection string containing embedded variables.
  • These can be resolved in one of the following ways:
    • by shell variable substitution (if the variables are presented as normal env-vars e.g. $FOO) by processes started from the shell
    • by config-utils templating: this assumes that the variable is presented in the form of ${env:...} and has been written to a config file
    • N.B. templating of env-vars themselves was considered but rejected as (re-)writing env-vars from Rust using the env library is not safe in a multithreaded environment
  • The operator is responsible for passing env-var names in the form that matches one of the above.
  • Some connections contain a driver-dependent prefix, depending on the context. The operator makes the decision which type of connection string to retrieve (e.g. postgresql/sqlalchemyuri or postgresql/celery).
  • Queues/brokers could be considered as being a subset of backends but have been kept separate as they were not specifically covered by ADR 29.

Jenkins 🟢 https://testing.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/airflow-operator-it-custom/75/
Openshift 🟢 https://testing.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/airflow-operator-it-custom/76/

Important

The logging test has been deactivated temporarily while testing this PR. Revert the setting before final approval/merging.

Definition of Done Checklist

  • Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
  • Please make sure all these things are done and tick the boxes

Author

  • Changes are OpenShift compatible
  • CRD changes approved
  • CRD documentation for all fields, following the style guide.
  • Helm chart can be installed and deployed operator works
  • Integration tests passed (for non trivial changes)
  • Changes need to be "offline" compatible
  • Links to generated (nightly) docs added
  • Release note snippet added

Reviewer

  • Code contains useful comments
  • Code contains useful logging statements
  • (Integration-)Test cases added
  • Documentation added or updated. Follows the style guide.
  • Changelog updated
  • Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

  • Feature Tracker has been updated
  • Proper release label has been added
  • Links to generated (nightly) docs added
  • Release note snippet added
  • Add type/deprecation label & add to the deprecation schedule
  • Add type/experimental label & add to the experimental features tracker

@adwk67 adwk67 self-assigned this Feb 6, 2026
@adwk67 adwk67 marked this pull request as ready for review February 9, 2026 07:52
@adwk67 adwk67 moved this to Development: Waiting for Review in Stackable Engineering Feb 9, 2026
@maltesander maltesander self-requested a review February 9, 2026 16:44
@maltesander maltesander moved this from Development: Waiting for Review to Development: In Review in Stackable Engineering Feb 9, 2026
Copy link
Member

@maltesander maltesander left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First batch of comments.

Comment on lines 39 to 41
pub struct GenericDb {
pub uri_secret: String,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The generic connection offers (generic) per product options (with more than a connection string) in the ADR29?
https://docs.stackable.tech/home/stable/contributor/adr/adr029-database-connection/#_product_specific_manifests

Copy link
Member Author

@adwk67 adwk67 Feb 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the decision we kind of decided to leave the generic option as simple as possible (at least for version 1), so I went with the single field we had in the proposal. Do you think that is OK? For the airflow impl, we don't need the other fields (driver, secret etc.), at least not until we have implemented templating for the generic option.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah did not see that one. Im fine with it, the question is only if we move that to op-rs, we could make it generic already if we see use cases for it. But referencing a secret and connection string is probably sufficient for most cases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't we need templating to be able to do something useful with the secret?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Templating where? Could you elaborate?

Copy link
Member Author

@adwk67 adwk67 Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I mean is: what can the "framework" code usefully do with the secret, other than supply its name to the operator? - it could read the secret (which we want to avoid), but other than that the secret has to be mounted (should be done in the operator) and the name of the associated env-var included in the connection string (but the name of the env-var should be provided by the operator, since it is doing the mounting) The name can be a constant coming from the framework code, which is only a small change from the current implementation.

Copy link
Member Author

@adwk67 adwk67 Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But then it is the operator that has to decide how this env-var name should be passed ($FOO or ${env:FOO}).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me this could be any arbitrary struct (just a secret reference or more fields). Even the secret referenced can have different entries that only the operator then knows about? It can mount it to pods etc, no need to read that?

Comment on lines +83 to +88
# TODO revert this before merging!
# - name: logging
# dimensions:
# - airflow
# - openshift
# - executor
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

marker!

uriSecret: redis-celery # <3>
----

<1> A reference to a secret which must contain the single fields `uri` e.g.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel URI is very generic. I think connectionString is a better description?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong feelings - I just went with what we had in the decision.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same, @sbernauer any opinions?

@sbernauer sbernauer self-requested a review February 10, 2026 08:46
Copy link
Member

@maltesander maltesander left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more doc reviews. Tests look good.

@adwk67
Copy link
Member Author

adwk67 commented Feb 11, 2026

Re-ran tests after latest changes 🟢 https://testing.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/airflow-operator-it-custom/77/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Development: In Review

Development

Successfully merging this pull request may close these issues.

credentialsSecret: split in multiple parts, make admin user optional

3 participants