Remove project override

[maveonair]

As discussed in this PR, we have decided to remove project overwriting in the provider configuration. If we want to do this correctly, we would need to rework the provider. And we believe that it is a better API if the change to the default project is instead defined explicitly in the resources.

[stgraber]

Storage pools are a global resource so they can't be tied to a project.

The bucket keys are a nested resource under a storage bucket which does have a project field.

[maveonair]

I start to realize that we have the project as an attribute for resources who actually are not tight to a project. Should we remove this then?

[stgraber]

I start to realize that we have the project as an attribute for resources who actually are not tight to a project. Should we remove this then?

Yeah, that's probably the better approach.
If something has a parent that's tied to a project, it shouldn't really have a project field of its own.

[stgraber]

Tests seem unhappy :)

[maveonair]

@stgraber I realized this change is more complex than expected. Today we rely on Incus to implicitly use the default project when the provider passes null. If project is set in the provider, it should override this behavior globally. My change does that, but it exposes a problem: once the provider always records a project in the Terraform state, we can no longer rely on the Incus server to infer the default. Setting project = null also does not force recreation, because the attribute is now marked as computed and Terraform always keeps the value returned by the server.

This leads to another problem too. If the project is set in the provider after resources already exist, resources without an explicit project will not be recreated, even though their effective project has changed.

That leaves us with two options:

1. Rework the provider so it fully owns project defaulting, and changing the provider project forces recreation of all resources without an explicit project, as this enforces consistency.
2. Remove the project attribute from the provider entirely.

I lean toward option 2. I prefer explicit behavior: if a specific project is desired, it should be set explicitly on the resource.

What do you think?

[stgraber]

Yeah, 2) seems like the way to go.

[maveonair]

@stgraber it looks like there is an issue with goreleaser now, which also affects the other PR created yesterday. Do you have already an idea how to fix it?

[jasisk]

it looks like there is an issue with goreleaser now, which also affects the other PR created yesterday. Do you have already an idea how to fix it?

Current Go stable (1.26) removed the win32 arm target completely (release notes) so I imagine it'll have to be added to the ignore list moving forward. Would open a PR myself but not sure what you want to do with oldstable.

Decided to just open the PR in case it's the direction you want to go in.