Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate the provider from OpenAPI? #556

Open
jmuchovej opened this issue Sep 19, 2024 · 3 comments
Open

Generate the provider from OpenAPI? #556

jmuchovej opened this issue Sep 19, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@jmuchovej
Copy link

Is your feature request related to a problem? Please describe.
It seems like only part of the REST API is integrated in the provider (totally understandable!). If it's possible to support the full REST API, that would be amazing.

Describe the solution you'd like
I've seen this work for other toolchains, though I've never taken a crack at this myself. However, it seems that with an OpenAPI spec, one could generate a Terraform Provider algorithmically (save, perhaps, for the aliasing).

To this end, I searched around for whether an OpenAPI spec exists and came across the following:

Documentation
Based on the forum post, there's exactly 0 documentation on this, as its not published by MikroTik. 😢

Additional context
Total novice at Go and Terraform Providers, but I'd be willing to take a crack at this, if this sounds like an interesting avenue to pursue for maintaining the provider.

@jmuchovej jmuchovej added the enhancement New feature or request label Sep 19, 2024
@vaerh
Copy link
Collaborator

vaerh commented Sep 19, 2024

In my opinion this seemingly promising topic contains many problems. There was an attempt to implement adding data sources based on JSON output, but even with this not everything is simple.
A few major problems that make it impossible to generate resources automatically based on restraml / JSON / CLI output: lack of built-in attribute description, lack of validation schemes, lack of uniformity of creation/update functions for all resources, impossibility of automatic decision making on suppression of reaction to attribute changes.
To my great regret now adding new resources is like manually creating a watch from Seiko to Breguet. Somewhere very easy, and somewhere quite complicated and costly.

Well, and of course the famous unexpected behavior of some MT resources. It is not frequent, but still occurs.

@jmuchovej
Copy link
Author

In my opinion this seemingly promising topic contains many problems.

Hehe, I think it's fair to upgrade this from an opinion to plain "facts". I looked more deeply into the RAML / JSON output from the link repo and much of what Terraform needs to work as intended, doesn't exist. (Like the validation schemas, among many others.)

Definitely saddened that there's no way to build the provider straight from the API. 😅 Feel free to close this if it helps with tracking things! 🙂

@tofkamp
Copy link

tofkamp commented Sep 21, 2024

The idea to make a provider from an API definition is great, but lacks a major component. The API is about which functions are available, and is not about objects and their state. With functions you can change the state of an object, but which function is for which object ? This is not (yet) defined in any common API specification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants