Clarify usage of `context` in SDK provider configuration logic, especially `GetCredentials` logic,

[SarahFrench]

Description

The use of context in the provider is a bit confusing due to:

1. using a mixture of ctx passed into functions, context.Background, context.TODO(), and c.Context stored on the Config struct
2. using some SDK methods related to context that are deprecated (schema.StopContext).

1) Context usage in func (c *Config) GetCredentials

Currently in func (c *Config) GetCredentials, where provider arguments are used to get a googleoauth.Credentials struct:

c.Context is used in 2 places:

• Handling of universe domain being set or unset when using credentials

context.Background is used in 2 places:

• Handling of universe domain being set or unset when using ADCs and not impersonating a service account

context.TODO() is used in 3 places:

• Handling of impersonating a service account using access_token
• Handling of impersonating a service account using credentials
• Handling of impersonating a service account using application default credentials

We may want to revisit this and clarify what context should be used where. We might want to use the context passed via the Config struct, or we might want to update functions like getTokenSource and GetCredentials to accept a ctx argument.

If we want to use the context passed via the Config struct we should check our usage of schema.StopContext, see below.

2) Usage of deprecated schema.StopContext

func schema.StopContext(ctx context.Context) (context.Context, bool) StopContext returns a context safe for global use that will cancel when Terraform requests a stop. This function should only be called within a ConfigureContextFunc, passing in the request scoped context received in that method.

Deprecated: The use of a global context is discouraged. Please use the new context aware CRUD methods.

We use schema.StopContext in func ProviderConfigure to make a 'stop context'. This context is passed into functions that lead up to handling credentials and configuring the client (see supporting info below).

Should schema.StopContext be removed? How would that affect configuration logic using that context?

Supporting info

Info about configuring the (SDK) provider; what leads up to using func (c *Config) GetCredentials?

How TF core tells the provider to configure itself:

• The SDK provider is configured using the provider's ConfigureContextFunc. All the configure logic is contained in func ProviderConfigure, which is used to set the ConfigureContextFunc.
  • When the SDK provider is configured the ConfigureContextFunc function "receives a context.Context that will cancel when Terraform sends a cancellation signal".

What happens inside ProviderConfigure:

• Prepares (and eventually returns) a Config struct
• Does stuff like pulling in values from configuration and ENVs, populates the Config struct
• Creates a stop context using schema.StopContext (here)
• Invokes func (c *Config) LoadAndValidate, which is needed to handle credentials and configure the client used by the provider etc.

What happens inside func (c *Config) LoadAndValidate:

• Sets the Context field in the Config struct using the stop context
• Calls func (c *Config) getTokenSource to get a token source. func (c *Config) GetCredentials is used to get a googleoauth.Credentials, which is required for making the token source.
  • Creating a googleoauth.Credentials requires passing in a context, but:
    • getTokenSource is not passed a context directly
    • GetCredentials uses a variety of contexts when making credentials for different auth methods (see section below)

New or Affected Resource(s)

N/A

Potential Terraform Configuration

N/A

References

No response

[SarahFrench]

Note: One of the potential causes of context-related errors in the plugin-framework implementation of configuration logic could be because the Context stored on the framework equivalent of the Config struct isn't a stop context..

Also, GetTokenSource and GetCredentials in the plugin-framework implementation passed context through as function arguments, versus what is described above in this issue for the SDK code.

GH issues related to context and the plugin-framework code:

• https://github.com/hashicorp/terraform-provider-google/issues/18774
• https://github.com/hashicorp/terraform-provider-google/issues/16832

[SarahFrench]

Labelled with plugin-framework as this was potentially a factor in some auth differences between the SDK and PF implementations of provider configuration logic; would be useful to know about in future