How to use conditional SchemaVersion?

[cbmdfc]

Hello,

I’m writing a custom terraform provider and one of the use cases is that an ID on the backend server looks X in version 1.0, but Y in version 1.1.

I thought about using a SchemaVersion and upgrade it if you’re using a backend 1.1… But then it wouldn’t work for those users connecting to 1.0. (Upgrading is required, but downgrading is impossible).

Is there any way to define a SchemaVersion that changes only if the migration was successfully applied?

[kpfleming]

That’s how it works. The stored schema version in the state isn’t changed unless the migration is completed successfully.

However, I don’t think that’s what you want to achieve: you want Terraform to not attempt the migration if it has been attempted before and failed.

[apparentlymart]

Hi @cbmdfc,

The schema version mechanism in the provider protocol and SDK is primarily intended to deal with changes to the provider’s own representation of the data, not to deal with changes to the upstream APIs. I think you’ll need to find a different strategy to manage this inconsistency in the remote API.

Here are some different options, though I’m not sure which one will work best for the details of your situation:

• Maintain two separate major releases of the provider, one targeting the 1.0 API and the other targeting the 1.1 API. Users can then choose which provider version to use based on which remote API version they are talking to.
• If the schemas between the two API versions are sufficiently similar, add logic into the provider codebase to abstract over the differences and produce equivalent results in both cases.
• If both API versions are available at once and users can choose between them, you could use versioned resource types as we see in some existing providers. For example, if your remote object were called a “thingy” and your provider were called “happycloud” then you could have a resource type named happycloud_thingy_v1_0 and another one named happycloud_thingy_v1_1 and then users can choose on a per-resource basis which version to use.

[kpfleming]

@apparentlymart

• If both API versions are available at once and users can choose between them, you could use versioned resource types as we see in some existing providers. For example, if your remote object were called a “thingy” and your provider were called “happycloud” then you could have a resource type named happycloud_thingy_v1_0 and another one named happycloud_thingy_v1_1 and then users can choose on a per-resource basis which version to use.

There are many examples of this: the AWS and OpenStack providers do it.