Skip to content

Conversation

bobbyiliev
Copy link
Contributor

Motivation

Adding details for the two different auth modes available in our terraform provider to prevent confusion in users.

Tips for reviewer

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

{{</ tab >}}

**Minimum requirements:** `terraform-provider-materialize` v0.8.1+
{{< tab "Self-hosted" >}}
Copy link
Contributor

Choose a reason for hiding this comment

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

Heh ... "Self-managed"

Comment on lines +78 to +88
**Important limitations for self-hosted mode:**

# Create an app password for the service user.
resource "materialize_app_password" "production_dashboard" {
name = "production_dashboard_app_password"
type = "service"
user = materialize_role.production_dashboard.name
roles = ["Member"]
}
Self-hosted configurations do **not** support Frontegg-dependent resources:
- `materialize_app_password`
- `materialize_user`
- `materialize_sso_config` and related SSO resources
- `materialize_scim_config` and related SCIM resources

# Allow the service user to use the "production_analytics" database.
resource "materialize_database_grant" "database_usage" {
role_name = materialize_role.production_dashboard.name
privilege = "USAGE"
database_name = "production_analytics"
region = "aws/us-east-1"
}
Only database resources are available (clusters, sources, sinks, schemas, etc.).
These organization and identity management resources require Materialize Cloud's
identity provider and will produce error messages if used in self-hosted mode.
Copy link
Contributor

Choose a reason for hiding this comment

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

Not quite sure this is characterized as a limitation. And we don't mention Frontegg anywhere, which is more of our implementation detail on the cloud side anyways. So, probably combine the lines 86-88 up here, kind of like:

The following resources apply only to Materialize Cloud and are not supported in self-managed configurations:

or

The following resources apply only to Materialize Cloud's identity provider and are not supported in self-managed configurations:

{{< warning >}}
**Migration warning:**

Switching between SaaS and self-hosted modes requires careful state file
Copy link
Contributor

Choose a reason for hiding this comment

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

SaaS -> Cloud?
self-hosted -> self-managed


Switching between SaaS and self-hosted modes requires careful state file
management as resource references and regional configurations differ between
modes. We strongly recommend using a consistent configuration mode from the
Copy link
Contributor

Choose a reason for hiding this comment

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

What does "using a consistent configuration mode" mean?
Does that mean don't migrate?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants