3 ms·

How will providers be handled? If Terraform changes the protocols and interfaces it sounds like a game of cat and mouse. The providers will support Terraform a

by re-thc 3y ago

How will providers be handled? If Terraform changes the protocols and interfaces it sounds like a game of cat and mouse. The providers will support Terraform and update to the latest framework, which may be incompatible with OpenTF at the time. Are we forking those too?

cube2222 3y ago
Initially we strive for 100% interoperability. The provider framework has been kept MPL, as have the providers, so we will keep being compatible. We will see what the longer-term future brings, and we'll react accordingly. We also have a bunch of ideas for improvements to the provider ecosystem and their capabilities, but those will go through the public RFC process once it's in place. Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
- jen20 3y ago
  > currently temporary Technical Lead of the OpenTF Project Assuming you aren't committing under pseudonyms, you've to date made a single contribution to Terraform, which was a fairly trivial change (b49655724d2f96f0e68196fb949a0d625abbd60e).
  - ahl 3y ago
    I don’t follow? You don’t think they can set up CI and migrate issues? It seems unlikely that there will be major breaking or architectural changes imminently.
    - jen20 3y ago
      I doubt that "clean room" fixes for each new commit in Terraform can be authored in order to maintain compatibility with the canonical source.
  - fishnchips 3y ago
    I pity anyone who underestimates Kuba. OK, most people I've worked with in tech are probably smarter than me, but this guy plays in a different league.
- maccard 3y ago
  Do you have an idea on where you stand on incompatible changes that are strict improvements over TF? As a concrete example, https://github.com/hashicorp/terraform/issues/13022 https://github.com/hashicorp/terraform/issues/13022 - My only read on this is that Hashicorp arent doing this as this removes a key selling point of Terraform Cloud.
  - cube2222 3y ago
    We're planning to stay 100% backwards compatible, and in the early stages we definitely want for it to be easy for people to migrate back and forth between both tools - even have teams with different engineers using different tools. DSL changes are honestly the thing we'd like to limit the most, but as long as they're backwards compatible, the RFC process will welcome them, and they will be discussed and considered! The important thing is for features to be opt-in. You should be able to limit yourself to a feature-set that is Terraform-compatible, if you want. If you want to use additional features on top of that, then that will be an option as well - we definitely want to innovate.
    - maccard 3y ago
      Thanks. I guess that's a little disappointing on one hand, but on the other makes perfect sense! FWIW, we're excited to see TF develop again
Coryodaniel 3y ago
HashiCorp manages a handful (~4 [0]) of the providers, while over 2,000 are managed by the community. I suspect breaking the interface would be further damaging to their reputation. The clouds will also have some influence around their provider. [0]: https://registry.terraform.io/browse/providers?tier=official https://registry.terraform.io/browse/providers?tier=official
- maccard 3y ago
  Right, but lets be honest, I don't care about 1995 of those providers. Nobody is using Terraform to manage spotify playlists [0]. The big ones are what matter, and (and HashiCorp manage the big ones) [0] https://registry.terraform.io/providers/conradludgate/spotify/latest/docs https://registry.terraform.io/providers/conradludgate/spotif...
  - Coryodaniel 3y ago
    I’m talking more along the lines of the 300 HashiCorp partners https://registry.terraform.io/browse/providers?tier=partner https://registry.terraform.io/browse/providers?tier=partner
    - maccard 3y ago
      In one swoop, we've gone from 2k to 300. I had a look at a handful of them, and they're ranging from 10-100 downloads a week. Our CI pulls the AWS provider more often than that. There's probably 20(?) from the 300 list that would actually cause enough outcry to be worth talking about, out of 2000 providers.
- re-thc 3y ago
  Except Hashicorp has already done something similar recently i.e. https://developer.hashicorp.com/terraform/plugin/framework/migrating https://developer.hashicorp.com/terraform/plugin/framework/m... So they can always do it again...
lijok 3y ago
Is Hashicorp were to change Terraform protocols without extremely good justification, the project would be dead immediately. The existence of Terraform in its current state is bringing billions in revenue to vendors like AWS and GCP. There's a lot of money at play. Hashicorp wouldn't risk that.
- fishnchips 3y ago
  It would be stupid cat-and-mouse game because it would make all previous versions of legacy Terraform irrelevant, and is unlikely to cause much harm in the long run because the same protocols can be implemented by other tools.
- re-thc 3y ago
  They already did do a Terraform, SDKv2 to plugin framework migration thing earlier [0] so why not again? [0]: https://developer.hashicorp.com/terraform/plugin/framework/migrating https://developer.hashicorp.com/terraform/plugin/framework/m...
figmert 3y ago
If they do, they likely have to give plenty of notice due to third party providers, and will still have to maintain the old protocol/a for older versions of all the providers.

by re-thc 3y ago

cube2222 3y ago

Initially we strive for 100% interoperability. The provider framework has been kept MPL, as have the providers, so we will keep being compatible. We will see what the longer-term future brings, and we'll react accordingly. We also have a bunch of ideas for improvements to the provider ecosystem and their capabilities, but those will go through the public RFC process once it's in place. Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.

jen20 3y ago
> currently temporary Technical Lead of the OpenTF Project Assuming you aren't committing under pseudonyms, you've to date made a single contribution to Terraform, which was a fairly trivial change (b49655724d2f96f0e68196fb949a0d625abbd60e).
- ahl 3y ago
  I don’t follow? You don’t think they can set up CI and migrate issues? It seems unlikely that there will be major breaking or architectural changes imminently.
  - jen20 3y ago
    I doubt that "clean room" fixes for each new commit in Terraform can be authored in order to maintain compatibility with the canonical source.
- fishnchips 3y ago
  I pity anyone who underestimates Kuba. OK, most people I've worked with in tech are probably smarter than me, but this guy plays in a different league.
maccard 3y ago
Do you have an idea on where you stand on incompatible changes that are strict improvements over TF? As a concrete example, https://github.com/hashicorp/terraform/issues/13022 https://github.com/hashicorp/terraform/issues/13022 - My only read on this is that Hashicorp arent doing this as this removes a key selling point of Terraform Cloud.
- cube2222 3y ago
  We're planning to stay 100% backwards compatible, and in the early stages we definitely want for it to be easy for people to migrate back and forth between both tools - even have teams with different engineers using different tools. DSL changes are honestly the thing we'd like to limit the most, but as long as they're backwards compatible, the RFC process will welcome them, and they will be discussed and considered! The important thing is for features to be opt-in. You should be able to limit yourself to a feature-set that is Terraform-compatible, if you want. If you want to use additional features on top of that, then that will be an option as well - we definitely want to innovate.
  - maccard 3y ago
    Thanks. I guess that's a little disappointing on one hand, but on the other makes perfect sense! FWIW, we're excited to see TF develop again

Coryodaniel 3y ago

HashiCorp manages a handful (~4 [0]) of the providers, while over 2,000 are managed by the community. I suspect breaking the interface would be further damaging to their reputation. The clouds will also have some influence around their provider. [0]: https://registry.terraform.io/browse/providers?tier=official https://registry.terraform.io/browse/providers?tier=official

maccard 3y ago
Right, but lets be honest, I don't care about 1995 of those providers. Nobody is using Terraform to manage spotify playlists [0]. The big ones are what matter, and (and HashiCorp manage the big ones) [0] https://registry.terraform.io/providers/conradludgate/spotify/latest/docs https://registry.terraform.io/providers/conradludgate/spotif...
- Coryodaniel 3y ago
  I’m talking more along the lines of the 300 HashiCorp partners https://registry.terraform.io/browse/providers?tier=partner https://registry.terraform.io/browse/providers?tier=partner
  - maccard 3y ago
    In one swoop, we've gone from 2k to 300. I had a look at a handful of them, and they're ranging from 10-100 downloads a week. Our CI pulls the AWS provider more often than that. There's probably 20(?) from the 300 list that would actually cause enough outcry to be worth talking about, out of 2000 providers.
re-thc 3y ago
Except Hashicorp has already done something similar recently i.e. https://developer.hashicorp.com/terraform/plugin/framework/migrating https://developer.hashicorp.com/terraform/plugin/framework/m... So they can always do it again...

lijok 3y ago

Is Hashicorp were to change Terraform protocols without extremely good justification, the project would be dead immediately. The existence of Terraform in its current state is bringing billions in revenue to vendors like AWS and GCP. There's a lot of money at play. Hashicorp wouldn't risk that.

fishnchips 3y ago
It would be stupid cat-and-mouse game because it would make all previous versions of legacy Terraform irrelevant, and is unlikely to cause much harm in the long run because the same protocols can be implemented by other tools.
re-thc 3y ago
They already did do a Terraform, SDKv2 to plugin framework migration thing earlier [0] so why not again? [0]: https://developer.hashicorp.com/terraform/plugin/framework/migrating https://developer.hashicorp.com/terraform/plugin/framework/m...

figmert 3y ago

If they do, they likely have to give plenty of notice due to third party providers, and will still have to maintain the old protocol/a for older versions of all the providers.