Support protocol version 6 #19
Comments
|
We will be adding a protov6 version of the A helper to convert between the two is out of scope for this package, and will be implemented in terraform-plugin-go-contrib. See hashicorp/terraform-plugin-go-contrib#7 |
7 tasks
bflad
added a commit
that referenced
this issue
Jan 12, 2022
Reference: #19 Reference: #33 In the near future, this project will be implementing multiple packages which will be reliant on shared logging details. Refactoring this code now will prevent duplication when those packages get created. This logging package structure is similar to what is being implemented in terraform-plugin-go, not only for code consistency, but in the event that portions or all of this project is subsumed into that project.
bflad
added a commit
that referenced
this issue
Jan 13, 2022
Reference: #19 Reference: #33 In the near future, this project will be implementing multiple packages which will be reliant on shared logging details. Refactoring this code now will prevent duplication when those packages get created. This logging package structure is similar to what is being implemented in terraform-plugin-go, not only for code consistency, but in the event that portions or all of this project is subsumed into that project.
bflad
added a commit
that referenced
this issue
Jan 13, 2022
Reference: #19 This new package implements a protocol version 6 compatible mux server. It is implemented similar to the existing protocol version 5 mux server, where validation and schema caching occurs upfront, then most RPCs act as a router. The main differences between the existing implementation and this new one are as follows: - Functionality is bundled into a package below the root package. - Naming is simplified and clarified. Previously, the capabilities of the mux server were believed to become much more dynamic, however in practice this never materialized due to the protocol. The mux server serves much more than a "Schema" so it is named "Mux" to prevent confusion. - There is no separation between a "Factory" and creating the mux server. There is not currently a benefit to introducing two layers of mux server handling. The main and only necessary entrypoint is a `NewMuxServer` function. - A `ProviderServer` method is provided to further simplify implementations, rather than needing a wrapping `func() tfprotov6.ProviderServer`. Once this package lands, the existing `SchemaServer` and `SchemaServerFactory` handling in the root package will be converted into a new `tf5muxserver` package with a similar API and structure as this one. That breaking change will occur afterwards before the next release.
bflad
added a commit
that referenced
this issue
Jan 20, 2022
Reference: #19 This new package implements a protocol version 6 compatible mux server. It is implemented similar to the existing protocol version 5 mux server, where validation and schema caching occurs upfront, then most RPCs act as a router. The main differences between the existing implementation and this new one are as follows: - Functionality is bundled into a package below the root package. - Naming is simplified and clarified. Previously, the capabilities of the mux server were believed to become much more dynamic, however in practice this never materialized due to the protocol. The mux server serves much more than a "Schema" so it is named "Mux" to prevent confusion. - There is no separation between a "Factory" and creating the mux server. There is not currently a benefit to introducing two layers of mux server handling. The main and only necessary entrypoint is a `NewMuxServer` function. - A `ProviderServer` method is provided to further simplify implementations, rather than needing a wrapping `func() tfprotov6.ProviderServer`. Once this package lands, the existing `SchemaServer` and `SchemaServerFactory` handling in the root package will be converted into a new `tf5muxserver` package with a similar API and structure as this one. That breaking change will occur afterwards before the next release.
bflad
added a commit
that referenced
this issue
Feb 2, 2022
Reference: #19 This new package implements a protocol version 6 compatible mux server. It is implemented similar to the existing protocol version 5 mux server, where validation and schema caching occurs upfront, then most RPCs act as a router. The main differences between the existing implementation and this new one are as follows: - Functionality is bundled into a package below the root package. - Naming is simplified and clarified. Previously, the capabilities of the mux server were believed to become much more dynamic, however in practice this never materialized due to the protocol. The mux server serves much more than a "Schema" so it is named "Mux" to prevent confusion. - There is no separation between a "Factory" and creating the mux server. There is not currently a benefit to introducing two layers of mux server handling. The main and only necessary entrypoint is a `NewMuxServer` function. - A `ProviderServer` method is provided to further simplify implementations, rather than needing a wrapping `func() tfprotov6.ProviderServer`. Once this package lands, the existing `SchemaServer` and `SchemaServerFactory` handling in the root package will be converted into a new `tf5muxserver` package with a similar API and structure as this one. That breaking change will occur afterwards before the next release.
bflad
added a commit
that referenced
this issue
Feb 2, 2022
…sion 6 implementation (#39) * Move existing root SchemaServer and SchemaServerFactory implementation to new tf5muxserver package * Migrate SchemaServer implementation to be similar to new protocol version 6 implementation Reference: #19 Reference: #37 Includes new internal tf5testserver package implementation.
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
With the merging of hashicorp/terraform-plugin-go#71, we now officially have two major protocol versions in the Terraform ecosystem. How do we want to handle muxing across them? Options I see:
hashicorp/terraform-plugin-sdk#737 tracks what the SDK is going to do, which should likely inform what we do. If the SDK goes proto6 for everything, then we may not need to do anything, really.
The text was updated successfully, but these errors were encountered: