Skip to content

Conversation

@adwk67
Copy link
Member

@adwk67 adwk67 commented Dec 22, 2025

Description

Warning

WIP: need to re-set to operator-rs version rather than PR branch.

Related to #382.
Tested with stackabletech/operator-rs#1121.

Tip

To test:

stackablectl op in airflow=0.0.0-pr725
./scripts/run-tests --skip-operator airflow --test versioning

Tests 🟢 https://testing.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/airflow-operator-it-custom/70/ (Openshift OKD 4.20)

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 marked this pull request as ready for review December 23, 2025 09:20
@adwk67 adwk67 linked an issue Dec 23, 2025 that may be closed by this pull request
@adwk67 adwk67 self-assigned this Dec 23, 2025
@adwk67 adwk67 moved this to Development: Waiting for Review in Stackable Engineering Dec 23, 2025
@adwk67 adwk67 moved this from Development: Waiting for Review to Development: In Progress in Stackable Engineering Dec 23, 2025
@adwk67 adwk67 moved this from Development: In Progress to Development: Waiting for Review in Stackable Engineering Jan 8, 2026
@sbernauer sbernauer requested a review from Techassi January 12, 2026 08:15
@Techassi Techassi moved this from Development: Waiting for Review to Development: In Review in Stackable Engineering Jan 12, 2026
Copy link
Member

Choose a reason for hiding this comment

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

note: We put the generated CRD in the top-level extra directory: extra/crds.yaml because Helm is no longer responsible for rolling out the CRD, the operator is.

Copy link
Member Author

Choose a reason for hiding this comment

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

With this change does make regenerate-charts still work as before?

Copy link
Member Author

Choose a reason for hiding this comment

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

I can change Makefile, but this will be overwritten by the next templating update. But neither does it make sense to do this globally until all product operators are versioned. I think this is best done as a chore once we reach that stage.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, this needs to be changed in the Makefile. We did the same thing for the secret-operator, see https://github.com/stackabletech/secret-operator/blob/0dd01ec27c9e53c20af526dbecf7bf034edddbf0/Makefile#L121-L123.

Additionally, the Tiltfile needs to be adjusted to not filter the manifests anymore.

These changes will eventually move into operator-templating, for now any rollouts need to be observed and manually adjusted that these changes are not overridden.

Copy link
Member Author

Choose a reason for hiding this comment

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

See 3e9f0f8

Comment on lines 7 to 9
{{- if .Values.maintenance.customResourceDefinitions.maintain }}
webhook.stackable.tech/conversion: enabled
{{- end }}
Copy link
Member

Choose a reason for hiding this comment

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

note: The Deployment itself technically doesn't need this label, only the Pod running the operator (and therefor the conversion webhook).

Copy link
Member Author

Choose a reason for hiding this comment

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

Done: 2a47b20

Comment on lines 120 to 122
{{- if .Values.maintenance.customResourceDefinitions.maintain }}
- create
{{- end }}
Copy link
Member

Choose a reason for hiding this comment

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

note: This is only needed when the operator wants/needs to deploy default custom resources, in this case an AirflowCluster. Is this the case here?

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, there are no default custom resources - I'll remove this. Thanks.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done: 2a47b20

Copy link
Member

Choose a reason for hiding this comment

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

question: This explicitly uses v1alpha2 to test the SSH access compared to the new test case "versioning", which tests that conversions works as expected, right?

Copy link
Member Author

@adwk67 adwk67 Jan 12, 2026

Choose a reason for hiding this comment

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

Yes, that's correct - the versioning test uses v1alpha1 intentionally and is the (only) one that explicitly tests that an expected conversion takes place. smoke uses v1alpha2. All the rest are left using v1alpha1, which I guess should be updated as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

(although no other tests use gitsync, which is the only thing affected by the version change)

Copy link
Member

Choose a reason for hiding this comment

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

The testing strategy we used for secret-operator looks like this: Leave everything as is, so v1alpha1 which basically tests conversion works across the board "for free".

Here, it might make sense to use the following approach:

  • Keep everything on v1alpha1 to get conversion testing "for free" across the board.
  • Introduce a dedicated SSH access test, which needs to use v1alpha2+ because the conversion is currently not loss-less. This will hopefully change once the required code is added in the #[versioned] macro.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's pretty much what we have: the gitsync test has two modes (https and ssh) and both use v1alpha2. Everthing else is left with v1alpha1.

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.

Feature Request: Airflow to support DAGs Git Sync using SSH Key

4 participants