Allow setting project at the provider level

[lgfa29]

Overview

Currently the Oxide project used in API calls needs to be set for each resource and data source. This creates a lot of unnecessary duplication and boilerplate.

Other providers (like aws and google), have similar concepts (region and project) that need to be defined on every API call, but they allow users to set them at the provider level. This becomes the default when resources and data sources don't specify a different value.

Implementation details

The provider schema needs to be update to accept a new (optional) project string attribute, and each resource and data source that have a project or project_id attribute needs to be updated to set this attribute to optional as well.

When making API calls, the provider must check the resource or data source value first, then fallback to the provider if not specified.

The provider variable could also be tied to a OXIDE_PROJECT environment variable.

Anything else you would like to add?

No response

[sudomateo]

I was doing a bunch of issue triage and such and I accidentally kept the discussion internal so I'm moving it here.

The more I think about this the more I don't think we should do it. Oxide projects as they exist today aren't a provider configuration concern and are instead a per-resource concern. There are resources that are contained within a project (e.g., instances) and resources that are rack level (e.g., silo, IP pool).

What do you think @lgfa29?

[sudomateo]

From @lgfa29.

I would personally still like to have this. The way I see it (and have used it in other providers) is that the provider-level project is kind of a default.

If you're managing a resource that lives above projects then it doesn't interfere with anything. If you're managing a resource from a different project you can override it in the resource itself. And if you are managing several resources across several projects then you're probably better off never setting it and keeping doing things as today.

[sudomateo]

Do you have some example configuration to support the why? I can see what you're getting at but I'm not exactly convinced yet. Mainly because project is required in a few resources and I'm unsure how resolving the provider attribute project with the resource attribute project would work.

Definitely not discouraging you advocating for this I'm just trying to better understand the why and ensure it's not something we'll want to backpedal on in the near future.

[lgfa29]

Sure! That's a fair question.

I think I wrote this while working on https://github.com/oxidecomputer/rancher-oxide-k8s-cluster-terraform and I remember being a little annoyed that I needed to keep adding project info to most resources and data sources (an aside, I think there's also some inconsistency on what information we use. Sometimes it's project_id and other times it's project_name. Probably best to consider this a separate issue though).

I'm a sample size of 1, so we probably should check with others, but I would imagine it to be equally annoying if the AWS required region to be set in every resource, or GCP for project. While not exactly the same concept I think they're similar enough in this case.

The way I normally organize my Terraform code (again, sample size of 1 😬) is that I usually have a root config for global resources and then separate root configs for things are related to each other that import values from the global state, and these related resources are usually located in the same region/project/whatnot.

I'm unsure how resolving the provider attribute project with the resource attribute project would work.

Basically the same way other providers do.

AWS: https://registry.terraform.io/providers/hashicorp/aws/latest/docs#region-1
GCP: https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference#project-1

In our case, I imagine it working like this:

provider "oxide" {
  project = "my-project"
}

provider "oxide" {
  alias   = "other"
  project = "my-other-project"
}

resource "oxide_instance" "my_instance" {
  ...
}

resource "oxide_instance" "my_other_instance" {
  provider = oxide.other
}

resource "oxide_instance" "some_other_instance" {
  project = "some-other-project"
}

resource "oxide_silo" "my_silo" {
  ...
}

• my_instance is created in my-project because it uses the default provider.
• my_other_instance is created in my-other-project because it uses the other provider (I'm not sure anyone would ever do this instead of explicit project, but 🤷).
• some_other_instance is created in some-other-project, overriding the default provider project.
• my_silo is global, so it ignores the provider project.