-
Notifications
You must be signed in to change notification settings - Fork 2
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
chore!: remove default org state #134
base: main
Are you sure you want to change the base?
Conversation
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.
This is a breaking change, and should only get added when we're ready for the 1.0 release.
Computed: true, | ||
Optional: true, |
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.
This should be Required
now, and also on all the other resources.
according to semver, every 0.0.x release is supposed to be considered "breaking". we could even do 0.1.x, but I think this is something we should get feedback from long before 1.0, not afterwards. |
That's fair - I just don't want to get in the habit of regularly breaking people's Terraform configs. My other hesitance is that this becomes annoying for the majority of single organization deployments. (Maybe a multi-org use-case ends up having multiple Terraform configs too, it's not unreasonable for different template admins to handle their IaC independently? Can't say for sure) I feel like we could make the experience 'safer' without sacrificing any of the convenience of the default. What would be your thoughts on keeping the |
data "coderd_organization" "default" {
is_default = true
}
resource "..." "..." {
organization_id = coderd_organization.default
} It's a tiny bit of extra code for them, but avoids a lot of complexity, confusion, and magic for everyone. |
I don't really agree that it adds a huge amount of complexity to the provider, user-facing or implementation wise, but I agree, it would be incredibly annoying for |
as an alternative to this, you should just do...
...and refer to
coderd_organization.default.id
when needed.What we're currently doing is not truly using the default organization, and hides details from the user that I think ultimately make the experience more dangerous and confusing.