[Bug] SNOW-1802641: provider organization_name and account_name when you only have an account locator
Terraform CLI Version
v1.9.1
Terraform Provider Version
v0.98.0
Company Name
No response
Terraform Configuration
provider "snowflake" {
account = "XYZ12345.us-east-1"
...
}
Category
category:resource
Object type(s)
Provider connection config, no specific resource.
Expected Behavior
With the account attribute of the provider config now deprecated, and with account locators continuing to be supported, it should be clear how to migrate to the new configuration when the old configuration only uses an account locator and doesn't use the ORGNAME-ACCOUNTNAME convention.
Actual Behavior
With the account attribute of the provider config now deprecated, and with account locators continuing to be supported, it is not clear how to migrate to the new configuration when the old configuration only uses an account locator and doesn't use the ORGNAME-ACCOUNTNAME convention.
Steps to Reproduce
Try to migrate the above HCL to the new provider configuration which requires an organization_name and an account_name, but with an account that only has an account locator.
For us, this happens with reader accounts (which aren't managed as properly named snowflake_account resources). And also with our ORGADMIN account, which, since it's only job is to manage other accounts, it never got a name itself.
How much impact is this issue causing?
Low
Logs
No response
Additional Information
https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/MIGRATION_GUIDE.md#behavior-change-deprecated-fields https://github.com/Snowflake-Labs/terraform-provider-snowflake/pull/3166
Would you like to implement a fix?
- [ ] Yeah, I'll take it 😎
Hi @jrobison-sb 👋
We'll add the link to the docs in our migration guide. I just want to confirm: are you able to use the new fields with reader and orgadmin accounts? I can't see that they have any limitations with the account name format.
@sfc-gh-jmichalak thanks for taking a look.
We'll add the link to the docs in our migration guide.
There's already a link here (where it says "Read more in the docs").
are you able to use the new fields with reader and orgadmin accounts?
I have not been able to do so, though I'm not entirely sure if it's user error on my part or something else. I tried it like this:
# The old way before the deprecation
provider "snowflake" {
account = "XYZ12345.us-east-1"
...
}
# My failed attempt at fixing the deprecation
provider "snowflake" {
organization_name = "MY_ORG_NAME"
account_name = "XYZ12345"
}
My failed attempt at fixing the deprecation crashed a terraform plan like this:
Error: open snowflake connection: 261004 (08004): failed to auth for unknown reason. HTTP: 404, URL: https://MY_ORG_NAME-XYZ12345.snowflakecomputing.com:443/...
If this is a case of user error and I need to try some other format or something, I'm happy to try whatever...
Thanks.
Yup, we have a link, but I think we should be more explicit here and at least mention the other account format.
I think your config is slightly incorrect. In our environments, the account name (in Format 1) does not match the account locator (in Format 2). Please make sure you use values from https://docs.snowflake.com/en/user-guide/admin-account-identifier#finding-the-organization-and-account-name-for-an-account or check them with
SELECT CURRENT_ORGANIZATION_NAME(), CURRENT_ACCOUNT_NAME();
These values should match organization_name and account_name in the config, respectively.
Thanks @sfc-gh-jmichalak, that unblocked me and I'm all good now. Thanks for taking the time to set me straight on this.
I'll leave this issue open in case there's a desire to use this issue to update the docs. Or if not, feel free to close this, I have no further questions.
Thanks.
I'm also facing an issue with this, even when using the proper org and account name as derived from above mentioned queries.
Old config (working in 0.97):
provider "snowflake" {
user = "myuser"
account = "${myaccount}.${myregion}"
role = "myrole"
authenticator = "JWT"
...
}
New config:
provider "snowflake" {
user = "myuser"
organization_name = "myorg"
account_name = "myaccount"
role = "myrole"
authenticator = "SNOWFLAKE_JWT"
...
}
I also tried to revert back to JWT with the new config but this did not work.
The error I get, after a few minutes, is:
Error: open snowflake connection: Post "https://MYORG-MYACCOUNT.snowflakecomputing.com:443/session/v1/login-request?requestId=[guid]&request_guid=[guid]&roleName=myrole": EOF
The above error was caused by firewall whitelisting on our end, which is pretty obvious in hindsight. But if people are reading this: please realize the URL is changed, so if you had specific whitelisting based on the old URL this will have to be amended/expanded.
Good pointer @maxnsdia. We will add it to the migration guide!
@sfc-gh-asawicki @sfc-gh-jmichalak Can we somehow still use account ~~identifiers~~ locators if we don't use to use organization_name + account_name? Today, we specifically use identifiers because account names may change for various reasons. We don't want all our tooling to break due to account name changes.
Hey @waffleshop. Do you mean account locators? If so, then pls read https://docs.snowflake.com/en/user-guide/admin-account-identifier, short extract from it:
The preferred account identifier consists of the name of the account prefixed by its organization
(e.g. myorg-account123). You can also use the Snowflake-assigned locator as the account identifier;
however, the use of this legacy format is discouraged.
@sfc-gh-asawicki Sorry. I meant locators. Forcing the organization_name + account_name format doesn't seem to allow for account locators.
Yes. This is aligned with the link (and extract) provided above.
It doesn't seem to be aligned, from my point of view. I understand using locators is discouraged. However, it is not deprecated. All current Snowflake packages, modules, and tools support locators today. The go package within this provider supports it too.
Hi @waffleshop :wave:
We're tracking this on our side. As stated in our roadmap, we're focusing on reaching GA. We'll be able to come back to this after GA. For now we recommend using organization_name and account_name fields.