dbt-materialize: support unmanaged clusters in deploy_init#36625
Merged
Conversation
The deploy_init macro previously hard-failed when the production cluster was unmanaged, blocking blue/green deployments for any Materialize user not on a managed cluster. Add a dispatch path that, for unmanaged origins, queries mz_cluster_replicas and emits CREATE CLUSTER ... REPLICAS (...) cloning each user-facing replica's SIZE and AVAILABILITY ZONE. Internal replicas are filtered via mz_internal_cluster_replicas. Replicas without a SIZE (orchestrated replicas using COMPUTECTL/STORAGECTL ADDRESSES) cannot be faithfully cloned and now produce a compiler error that names the offending replica. The new create_unmanaged_cluster macro mirrors the structure of the existing create_cluster macro (pre-existence check, CI tag re-entry, DDL emission, CI tag set) so the managed path is untouched. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
bobbyiliev
requested changes
May 20, 2026
|
|
||
| * Support unmanaged origin clusters in `deploy_init`. The deployment | ||
| cluster is now created by cloning the production cluster's replicas | ||
| (including SIZE and AVAILABILITY ZONE attributes). Internal replicas |
Contributor
There was a problem hiding this comment.
Tiny nit: "Internal replicas are skipped" might confuse users who don't know what counts as internal. Worth a quick clarifier, or fine to leave?
Contributor
Author
|
@bobbyiliev thank you for the speedy review. I believe I've addressed your comments. |
bobbyiliev
approved these changes
May 20, 2026
Contributor
bobbyiliev
left a comment
bobbyiliev
left a comment
There was a problem hiding this comment.
Looks good! There seem to be some minor lint CI failures but should be good to go after that.
sjwiesman
added a commit
that referenced
this pull request
May 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The deploy_init macro previously hard-failed when the production cluster was unmanaged, blocking blue/green deployments for any Materialize user not on a managed cluster. Add a dispatch path that, for unmanaged origins, queries mz_cluster_replicas and emits CREATE CLUSTER ... REPLICAS (...) cloning each user-facing replica's SIZE and AVAILABILITY ZONE. Internal replicas are filtered via mz_internal_cluster_replicas. Replicas without a SIZE (orchestrated replicas using COMPUTECTL/STORAGECTL ADDRESSES) cannot be faithfully cloned and now produce a compiler error that names the offending replica.
The new create_unmanaged_cluster macro mirrors the structure of the existing create_cluster macro (pre-existence check, CI tag re-entry, DDL emission, CI tag set) so the managed path is untouched.
Remove these sections if your commit already has a good description!
Motivation
Why does this change exist? Link to a GitHub issue, design doc, Slack
thread, or explain the problem in a sentence or two. A reviewer who has
no context should understand why after reading this section.
If this implements or addresses an existing issue, it's enough to link to that:
Closes
Fixes
etc.
Description
What does this PR actually do? Focus on the approach and any non-obvious
decisions. The diff shows the code --- use this space to explain what the
diff can't tell a reviewer.
Verification
How do you know this change is correct? Describe new or existing automated
tests, or manual steps you took.