Hi, does terraform has some mandatory quality assurance requirements for 3rd party providers? With certain 3rd party provider, I have had more issues opened within a few months than I had for all other hashicorp providers combined over the years. I understand I have to deal with the specific vendor, however the problems are mainly due to serious lacking of understanding and respect on how terraform should work. For example, terraform plan not working due to lack of proper input validations and error handling, terraform debug doesn’t work due to lack of necessary debug messages(with debug enabled, resource/app specific error messages are the same as without debug except the extra message from SDK. resource doesn’t work as declarative, but as imperative/procedural(even acknowledged from vendor saying that’s ok)., etc.
With this kind of the implementation, does hashicorp has any influence on the vendor given the terraform experience is completely ruined?
Hi @master,
On the main Terraform Registry there are currently three tiers of providers which have different expectations:
- “Official” providers are released directly by HashiCorp staff and so the relevant team at HashiCorp has direct control over what does and does not get included into a release.
- “Partner” providers are released by particular vendors who have a partner relationship with HashiCorp. These vendors are in control of what’s included in their provider releases but the partnership agreements describe certain obligations that each party (vendor and HashiCorp) will follow.
- “Community” providers can be uploaded by anyone without any involvement from anyone at HashiCorp. Providers can in principle be retroactively removed if they are found to contain e.g. malicious code, but there is no prior approval required to publish a new provider or a new release of an existing provider.
The providers in the Community tier do not have any quality requirements, so if you choose to use community-maintained providers you will need to research the design and implementation quality yourself. This tier-based system is a compromise to allow low-friction publishing for those who want to share providers primarily for their own use that others might find useful while also helping users of providers to understand what level of “vetting” might be required for each provider based on the author’s relationship with HashiCorp.
Hi @apparentlymart, thanks for the info. So for an large commercial company that about the same sizes compared to GCP, Azure, AWS, IBM, Oracle etc., if they don’t have partnership with hashicorp and release their provider under “vendor_name/provider_name”, does that fall into community as well and thus no any code quality requirements(not malicious code, just terrible coding practice which breaks many terraform basic functions at the most fundamental level)?
While HashiCorp does maintain a registry of approved Terraform providers, they do not have direct control over the development and maintenance of each provider. However, they do review and validate providers that are submitted to the registry to ensure they adhere to certain guidelines and standards.
If you are encountering significant issues and believe the quality of a specific third-party provider is severely impacting your Terraform experience, it is advisable to reach out to both the provider and HashiCorp to express your concerns. HashiCorp may be able to provide guidance or suggestions to the provider based on the best practices and principles of Terraform.
Hi @johnanthony6543, thanks. this is the exact reason I raised the question here. Is your answer the official stand from hashicorp or just your personal opinion? The provider in question is from one of the big companies, but terraform plan and resource are definitely not working the way they should be. some basic examples are, they don’t even handle null value correctly, terraform plan doesn’t show the correct plan and apply fails even plan passes, and resource not even work as declarative(with official answer from the vendor saying that’s the way they are doing them, a direct “translation” from product specification which are likely meant for traditional imperative programming. lol). I am working with the vendor to address these issues, but wonder if hashicorp has any influence on situation like this even if it falls under “community” given the implementation really badly ruins the terraform experience.
Hi @master,
Ultimately the “community” tier in the Terraform Registry is very similar to open registries for other languages like e.g. NPM for JavaScript, PyPI for Python, crates.io for Rust: it’s open for anyone to publish and experiment, but as a consequence the quality of these libraries is not dependable (providers are essentially a special kind of library for Terraform).
Unfortunately that does indeed mean that some providers published there will be poorly designed, or buggy, or otherwise undesirable. If you use community providers then you will need to review them yourself to decide if they are useful and usable.
Unlike some other language registries, Terraform Registry also has the sense of Official and Partner tiers where the goal is to draw more attention to providers that are expected to meet a certain level of quality, so that folks using those providers can reduce the amount of manual review they need to do.
If the vendor you are concerned about does not want to form a partnership then indeed there is little HashiCorp can do to influence the design of their provider. They are in the same category as e.g. the random utility providers that some folks have published, such as my personal projects apparentlymart/javascript that exposes a JavaScript interpreter into Terraform as a data source. I expect lots of Terraform users would find that a dubious idea outside of Terraform’s scope, but since it’s a community provider in my personal namespace HashiCorp does not influence it (except that of course I have an employment relationship with HashiCorp and so they do have some influence over me.)
I’m not sharing this to imply that this means that the situation with the provider you have tried to use is the best situation, but ultimately it’s up to each individual community member how to design their provider and up to each user of Terraform to decide if a particular community provider will meet their needs, just as is true for community-contributed libraries in other language ecosystems. The situation would be similar if, for example, the official JavaScript client library for the same remote system were poorly designed. If the vendor is not open to the feedback being offered then a potential last-resort alternative is to fork the provider and publish your own unofficial variant, though of course that is not an option without cost
@master: For your information, here is a link to the documentation detailing the various badges and their meanings in the registry: Terraform Registry - Providers Overview | Terraform | HashiCorp Developer
Thanks!
Great Thanks! @CraigW This is really useful to confirm the status.
Thanks again. @apparentlymart. From the info just got from @CraigW, Looks like I am working with a partner provider. I though partners are always under hashicorp namespace which looks like not the case.
So, are those obligations for partner public knowledge that I can find somewhere, or it’s considered trade secret?
Also is there any fine technical requirement related to terraform resource behavior? I found this: Resource Behavior - Configuration Language | Terraform | HashiCorp Developer, but it’s still too high level.
I am looking for the expected/required coding behavior. for example, from my personal experience with AWS/GCP/Azure, the resource code should figure out, based on required arguments, what customers want to do, apply only the applicable optional arguments, ignore the extra, and only error out when required are missing/wrong and/or applicable optional arguments are wrong. Not sure if this is an enforced, or at least documented best practices somewhere, or just happen everyone is doing a good job following this route?