-
Notifications
You must be signed in to change notification settings - Fork 157
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
Workspace id migration #106
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.
I'm not sure if it makes sense to do this now or to plan to do it later but this does introduce some inconsistencies with workspace_id
vs workspace_external_id
.
Policy sets and notification configurations both use workspace_external_id
. It would be nice if everything could use workspace_external_id
or if policy sets and notification configurations could be switched to just use workspace_id
.
I think I lean more toward workspace_id
for everything since go-tfe and the API both seem to use workspace id to refer to the external id. Is this something that would be reasonable to change with this release (if we are already introducing breaking changes)? Or something you'd prefer to wait to do?
I don't think we can remove workspace.external_id
until we sort this out.
I think this is a perfect use case for the service discovery logic I've build into the remote backend, this provider and TFC/TFE. Currently this provider supports the TFE services v2 and v2.1 (https://github.com/terraform-providers/terraform-provider-tfe/blob/master/tfe/provider.go#L27). So if you would update the service version in TFC/TFE (and of course configure the needed things in CheckPoint) you should be able to use the supported version to decide if you want to migrate the state or not. I believe that you can support multiple versions in TFC/TFE concurrently and the remote backend and this provider will try to use the latest commonly supported version. But not sure anymore how this looks in Altas 😉 Either way I would strongly suggest to use the service version logic as it's specifically added for things like this. Hope this helps! |
Fully agree on that @lafentres! The only reason |
Thanks y'all. Yeah, I agree that we should update everything to use Will give updating the testing a bit a try based on y'all's comments, and see if I can figure out how to get the service discovery endpoint used. |
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.
The updates look good to me! I tested the state migration with a simple config and it everything looks like it worked.
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.
Didn't test things myself, but had a quick look through the PR...
* `id` - The workspace's human-readable ID, which looks like | ||
`<ORGANIZATION>/<WORKSPACE>`. | ||
* `id` - The workspace's opaque external ID, which looks like | ||
`ws-<RANDOM STRING>`. | ||
* `external_id` - The workspace's opaque external ID, which looks like |
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 think we should now remove this field right?
* `id` - The workspace's human-readable ID, which looks like | ||
`<ORGANIZATION>/<WORKSPACE>`. | ||
* `id` - The workspace's opaque external ID, which looks like | ||
`ws-<RANDOM STRING>`. | ||
* `external_id` - The workspace's opaque external ID, which looks like |
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 one should be removed right? No point in exporting the same ID twice with a different name.
|
||
log.Printf("[DEBUG] Read configuration of workspace: %s", name) | ||
workspace, err := tfeClient.Workspaces.Read(ctx, organization, name) | ||
id := d.Id() |
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 perfectly valid, but it's also very common and fine to just call d.Id()
everywhere the ID is needed.
Thanks for the feedback y'all. TLDR; I'm not planning on merging this until late January. We had to update the version of the API in the Atlas discovery doc and make that the only allowed version for this version of the provider. That will likely not make it into PTFE until late January. Therefore, we should hold off on merging this until it is supported by PTFE. |
Co-Authored-By: Sander van Harmelen <sander@vanharmelen.nl>
|
We are very much interested in this and looking forward to it being released. Is this still planned to be merged sometime soon? |
|
Even porting to the new workspace_id format, I still receive this error on new variables |
This just broke all of our bindings |
Howdy folks. First, I'm sorry for pushing out this change without better communication. We are working to improve our process on this provider so we can avoid such situations in the future. The underlying reason for this change was that the workspace's ID in the You can fetch the workspace's external id and use it in the variable resource by using the
When this provider was originally created, the API did not support the using the workspace's external_id to update these resources, and it does now. This provider is still pre-1.0, but we still strive to not make any disruptive changes between releases - this one just needed to be done, and hopefully the validation describing that you now need to use the workspace ID makes the path forward clear. Sorry for the disruption, and thanks! |
Also as a reminder, you can always pin your provider versions. e.g.
|
This PR migrates the schema of workspaces to use the workspace's immutable
external_id
as the id, instead of the mutableorganization/workspace
identifier.The variables and team_access resources also have a
workspace_id
field, which is migrated to the newworkspace.id
as well. Additionally, the team_access and workspace data source have been updated accordingly, though those don't require a state migration.Background comment from @apparentlymart
Todo:
Adjust the state upgraders to not upgrade if theAlso not going to do this as it seems extremely corner casey.workspace_id
is already theexternal_id
.Notes