-
-
Notifications
You must be signed in to change notification settings - Fork 3
feat: Replace credentials-secret with db/broker connection(s) #743
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
docs/modules/airflow/examples/getting_started/code/airflow.yaml
Outdated
Show resolved
Hide resolved
docs/modules/airflow/examples/getting_started/code/airflow.yaml
Outdated
Show resolved
Hide resolved
docs/modules/airflow/examples/getting_started/code/airflow.yaml
Outdated
Show resolved
Hide resolved
docs/modules/airflow/examples/getting_started/code/airflow.yaml
Outdated
Show resolved
Hide resolved
maltesander
left a comment
There was a problem hiding this 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.
| pub struct GenericDb { | ||
| pub uri_secret: String, | ||
| } |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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}).
There was a problem hiding this comment.
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?
tests/templates/kuttl/versioning/30-install-airflow-cluster.yaml.j2
Outdated
Show resolved
Hide resolved
| # TODO revert this before merging! | ||
| # - name: logging | ||
| # dimensions: | ||
| # - airflow | ||
| # - openshift | ||
| # - executor |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same, @sbernauer any opinions?
Co-authored-by: Sebastian Bernauer <[email protected]>
Co-authored-by: Sebastian Bernauer <[email protected]>
Co-authored-by: Sebastian Bernauer <[email protected]>
Co-authored-by: Sebastian Bernauer <[email protected]>
Co-authored-by: Malte Sander <[email protected]>
Co-authored-by: Malte Sander <[email protected]>
Co-authored-by: Malte Sander <[email protected]>
Co-authored-by: Malte Sander <[email protected]>
Co-authored-by: Malte Sander <[email protected]>
Co-authored-by: Malte Sander <[email protected]>
Co-authored-by: Malte Sander <[email protected]>
…cluster.yaml.j2 Co-authored-by: Malte Sander <[email protected]>
…uster.yaml.j2 Co-authored-by: Malte Sander <[email protected]>
…ml.j2 Co-authored-by: Malte Sander <[email protected]>
…r.yaml.j2 Co-authored-by: Malte Sander <[email protected]>
maltesander
left a comment
There was a problem hiding this 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.
Co-authored-by: Malte Sander <[email protected]>
…l.j2 Co-authored-by: Malte Sander <[email protected]>
|
Re-ran tests after latest changes 🟢 https://testing.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/airflow-operator-it-custom/77/ |
Description
Fixes #64
Decision: https://github.com/stackabletech/decisions/issues/72
Notes for reviewers
database.rs,queue.rsandconnection.rs.$FOO) by processes started from the shell${env:...}and has been written to a config fileenvlibrary is not safe in a multithreaded environmentJenkins 🟢 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
Author
Reviewer
Acceptance
type/deprecationlabel & add to the deprecation scheduletype/experimentallabel & add to the experimental features tracker