-
Notifications
You must be signed in to change notification settings - Fork 674
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
Add notes to selfAuth with Azure docs #4835
Add notes to selfAuth with Azure docs #4835
Conversation
Signed-off-by: davidmirror-ops <david [email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4835 +/- ##
==========================================
+ Coverage 58.98% 59.68% +0.70%
==========================================
Files 567 645 +78
Lines 44496 49534 +5038
==========================================
+ Hits 26244 29563 +3319
- Misses 15858 17396 +1538
- Partials 2394 2575 +181
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
||
11. Restart ``flytescheduler``` to start using authenticated requests: | ||
10. Verify that the `flytepropeller`, `flytescheduler` and `flyteadmin` Pods are restarted and Running: |
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's the reason to remove the instructions on how to restart the deployments (kubectl rollout restart ...
) in the docs?
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.
Because once the Helm release is upgraded, it triggers redeployment of those services
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 left a few small suggestions, but otherwise LGTM!
|
||
.. prompt:: bash $ | ||
For `multi-cluster deployments <https://docs.flyte.org/en/latest/deployment/deployment/multicluster.html>`__, this secret definition has to be added to the `values-dataplane.yaml` file. |
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 `multi-cluster deployments <https://docs.flyte.org/en/latest/deployment/deployment/multicluster.html>`__, this secret definition has to be added to the `values-dataplane.yaml` file. | |
For `multi-cluster deployments <https://docs.flyte.org/en/latest/deployment/deployment/multicluster.html>`__ running `flytepropeller` in the control plane cluster, you must add this secret definition to the `values-dataplane.yaml` file. |
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'm trying not to get lost in grammar :) The idea is: in every cluster where propeller is running you need that secret (not only environments where propeller is running on the control plane cluster).
Propeller in the control plane cluster is optional, for the data plane is a must.
Let me know if it's clear or not
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.
Gotcha, then I would suggest:
For `multi-cluster deployments <https://docs.flyte.org/en/latest/deployment/deployment/multicluster.html>`__, you must add this secret definition to the `values-dataplane.yaml` file.
|
||
.. prompt:: bash $ | ||
For `multi-cluster deployments <https://docs.flyte.org/en/latest/deployment/deployment/multicluster.html>`__, this secret definition has to be added to the `values-dataplane.yaml` file. | ||
There's no need to create this secret in the control plane cluster if you're not running `flytepropeller` there. |
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.
There's no need to create this secret in the control plane cluster if you're not running `flytepropeller` there. | |
If you are not running `flytepropeller` in the control plane cluster, you do not need to create this secret there. |
Signed-off-by: davidmirror-ops <david [email protected]>
Signed-off-by: davidmirror-ops <david [email protected]>
* Add notes from recent Azure deployments Signed-off-by: davidmirror-ops <david [email protected]> * Rephrase multicluster auth Signed-off-by: davidmirror-ops <david [email protected]> * Rephrase multicluster auth v2 Signed-off-by: davidmirror-ops <david [email protected]> --------- Signed-off-by: davidmirror-ops <david [email protected]> Co-authored-by: davidmirror-ops <david [email protected]> Signed-off-by: Katrina Rogan <[email protected]>
* Add notes from recent Azure deployments Signed-off-by: davidmirror-ops <david [email protected]> * Rephrase multicluster auth Signed-off-by: davidmirror-ops <david [email protected]> * Rephrase multicluster auth v2 Signed-off-by: davidmirror-ops <david [email protected]> --------- Signed-off-by: davidmirror-ops <david [email protected]> Co-authored-by: davidmirror-ops <david [email protected]>
Why are the changes needed?
From recent interactions with Flyte deployments with Azure as IdP, some precisions are needed in the selfAuth docs.
What changes were proposed in this pull request?
How was this patch tested?
Setup process
Screenshots
Check all the applicable boxes
Related PRs
Docs link