Skip to content
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

[Bug]: provider organization_name and account_name when you only have an account locator #3198

Open
1 task
jrobison-sb opened this issue Nov 13, 2024 · 12 comments
Assignees
Labels
docs Used to mark issues with documentation remark/questions

Comments

@jrobison-sb
Copy link
Contributor

jrobison-sb commented Nov 13, 2024

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
#3166

Would you like to implement a fix?

  • Yeah, I'll take it 😎
@jrobison-sb jrobison-sb added the bug Used to mark issues with provider's incorrect behavior label Nov 13, 2024
@sfc-gh-jmichalak sfc-gh-jmichalak self-assigned this Nov 14, 2024
@sfc-gh-jmichalak sfc-gh-jmichalak removed the bug Used to mark issues with provider's incorrect behavior label Nov 14, 2024
@sfc-gh-jmichalak
Copy link
Collaborator

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 sfc-gh-jmichalak added the docs Used to mark issues with documentation remark/questions label Nov 14, 2024
@jrobison-sb
Copy link
Contributor Author

jrobison-sb commented Nov 14, 2024

@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.

@sfc-gh-jmichalak
Copy link
Collaborator

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.

@jrobison-sb
Copy link
Contributor Author

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.

@maxnsdia
Copy link

maxnsdia commented Nov 20, 2024

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

@maxnsdia
Copy link

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.

@sfc-gh-asawicki
Copy link
Collaborator

Good pointer @maxnsdia. We will add it to the migration guide!

@waffleshop
Copy link
Contributor

waffleshop commented Dec 5, 2024

@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.

@sfc-gh-asawicki
Copy link
Collaborator

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.

@waffleshop
Copy link
Contributor

@sfc-gh-asawicki Sorry. I meant locators. Forcing the organization_name + account_name format doesn't seem to allow for account locators.

@sfc-gh-asawicki
Copy link
Collaborator

Yes. This is aligned with the link (and extract) provided above.

@waffleshop
Copy link
Contributor

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.

sfc-gh-jmichalak added a commit that referenced this issue Dec 10, 2024
<!-- Feel free to delete comments as you fill this in -->
- prove that using network policy with lowercase characters in oauth
integration fails in Snowflake
- update the migration guide regarding migrating provider configuration
- rename `datasource` to `data source`
- add missing examples and fix some examples in the docs
- add notes about missing fields (they will be done in SNOW-1844996)
- adjust documentation for provider configuration
- improve quoting with import and resource configuration examples
- some examples of replication and grants were not changed because they
show a nicer setup, IMO - can discuss about this
- add info about external changes not being detected for certain fields
or resource types
- change infobox format for some notes (`[!WARNING]` -> `!> Note`)
because it isn't rendered properly in the registry
- fix empty `using` in view masking policies
- add links to documentation of the referenced resources
- adjust enum validations to use `sdkValidation` with SDK converter
function instead of `StringInSlice`
- address
#3247
by improving the documentation
- update lists in `v1-preparations` files
<!-- summary of changes -->

## Test Plan
<!-- detail ways in which this PR has been tested or needs to be tested
-->
* [ ] acceptance tests
<!-- add more below if you think they are relevant -->
* [x] integration tests

## References

#3198

#3251
## TODO (next PRs):
- check the migration guide once again
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Used to mark issues with documentation remark/questions
Projects
None yet
Development

No branches or pull requests

5 participants