Versioning of provider schemes

[vaerh]

To keep our discussion from drowning in pull requests, I'll announce it here.
I'm interested in how we can cover with AlwaysPresentNotUserProvided incremental changes to existing schemas?
What I see at first glance with AlwaysPresentNotUserProvided is:

• Inability to have up-to-date and consistent schemas of the latest version of ROS.
• Inability to use validators when the vendor changes the set of valid values.

That said, I am extremely keen on not being able to support inter-version updates to the state file. In any case, it seems very complicated to me now.

[dokmic]

@vaerh Let's first try to list all already existing and potential cases:

1. Adding new property.
2. Removing a property.
3. Changing default value.
4. Changing accepted values (like what happened to speed and advertise props in ethernet interfaces in 7.12).
5. Changing property type (e.g., set or list instead of regular string).

I think (1), (2), and (3) can be handled by AlwaysPresentNotUserProvided as they won't be sent in the request if the user hasn't used them explicitly. (4) is a bit tricky, but we can extend accepted values to cover all the versions. It will be up to the user what option to use. (5) is unlikely, but we can always go with a regular string in the worst case.

And regarding the points you raised:

Inability to use validators when the vendor changes the set of valid values.

We can widen the validator to cover both versions.

Inability to have up-to-date and consistent schemas of the latest version of ROS.

I don't think adding versioning solves this problem, as all the properties should be listed anyway. And even if we manage to segregate schemas, we still have properties like PoE, which support depending on the hardware.

[dokmic]

From the implementation side, we are using terraform-plugin-sdk which is also limiting us in implementing seamless versioning. The ProviderFunc requires us to return the resources map before accessing provider configuration, so we cannot toggle some shema props based on that. In #271, you used a workaround with an environment variable, but if you are using local modules to manage two devices with different versions, it doesn't work correctly.

DefaultFunc and ValidateFunc have no context, and we cannot directly access the Mikrotik client instance to gather the current version. We can try to resolve this with closures, but it will require some effort since Terraform parallelizes operations.

Also, using if statements in schema definition is not a good approach, in my opinion. We currently have more or less a declarative structure in most providers, but if can ruin that.

[dokmic]

As a potential solution, we can try to migrate to terraform-plugin-framework. It supports context, and schema can be constructed dynamically, so it should be possible to have seamlessly versioned schemas.

It also requires some effort, but it's a long-term win as the SDK will be deprecated eventually.

What I think is really important at the moment is to add all the versions up to 7.13 to the pipeline and fix what's failing using existing functionality. Also, the new WiFi package and updated CAPsMAN are coming in 7.13 to replace the good old wireless (and we should probably implement those beforehand). That's an excellent example of how Mikrotik rolls out breaking changes -- it's under another REST endpoint and doesn't require implementing any versioning on the provider side.

[vaerh]

Yes, I agree with all of the above. Using environment variables is a crutch, which is the only thing we can offer within the existing SDK.
We should think three times about moving to a framework. I implemented support for cloud-init drive just using the framework to look at its functionality. And, unfortunately, I can state several unpleasant moments:

• Mandatory description of the resource structure together with the schema, although it is probably possible to write a generator from an existing schema. It is necessary to think.
• Lack of possibility to use DiffSuppress functions. Also there should be an unambiguous correspondence between data in HCL scripts and data in the state file. But this was more of a problem for my CID.
• The serializer will need to be redesigned, for the new structures (attributes and blocks).
• Probably something else.

I will try to move the provider to a modular structure in the near future. I want to get away from one directory with an infinite number of files and group them by functionality. Be prepared for that.
I hope that in the future it will make our life easier when versioning schemes (if we go the way: new schema - new file).