-
Notifications
You must be signed in to change notification settings - Fork 482
docs: Add rollout guidance for Self-Managed auth #34202
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?
docs: Add rollout guidance for Self-Managed auth #34202
Conversation
- Removes "kind" references since instructions are generic to the Materialize CR - Adds references to the Materialize CR fields - Adds how to actually deploy authentication with notice about accidentally overriding values.
| Password authentication requires users to log in with a password. | ||
|
|
||
| To configure Self-Managed Materialize for password authentication: | ||
| To configure Self-Managed Materialize for password authentication, update the following fields in the [Materialize CR](/installation/appendix-materialize-crd-field-descriptions/): |
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.
So ... let's remove the link here ... because that page just gives all the fields ... and we're giving the specific fields here.
We could go "For all Materialize CR settings, see ... "
| compatible with PostgreSQL clients that support SCRAM-SHA-256. | ||
|
|
||
| To configure Self-Managed Materialize for SASL/SCRAM authentication: | ||
| To configure Self-Managed Materialize for SASL/SCRAM authentication, update the following fields in the [Materialize CR](/installation/appendix-materialize-crd-field-descriptions/): |
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.
ditto.
| For more information on rollout configuration, view our [installation overview](/installation/#rollout-configuration). | ||
| {{< warning >}} |
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.
Could we repeat this warning in both places above where we talk about setting authenticatorKind?
It's important enough that I think repeating in throughout (as people hop onto just their interested section)
- Colocate warning about the `authenticatorKind` with authenticatorKind section - Just reference link to Materialize CR rather than point to it.
kay-kim
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.
On my side, LGTM. But left comment for Justin and Sid.
| requestRollout: <SOME_NEW_UUID> # Generate new UUID for rollout | ||
| forceRollout: <SOME_NEW_UUID> # Rollout without requiring a version change | ||
| # Tears down the prior version and restarts the current Materialize instance | ||
| rolloutStrategy: ImmediatelyPromoteCausingDowntime |
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.
@jubrad and @sidsaw-mz ... any concerns about using the ImmediatelyPromoteCausingDowntime strategy here?
Motivation
Tips for reviewer
Checklist
$T ⇔ Proto$Tmapping (possibly in a backwards-incompatible way), then it is tagged with aT-protolabel.