NETCONF vs RESTCONF
Closed this issue · 4 comments
This a mere question: Why is this provider using RESTCONF instead of NETCONF?
The main difference is how the payload is sent, but NETCONF has been around longer, but NETCONF would be compatible with older devices.
NETCONF is not a good fit for Terraform as it relies on a two stage commit process. In Terraform there is no concept of doing a "final" operation (like a commit) after applying all resources, so we would need do a commit for each and every resource separately. Also, I am not aware of any actively maintained NETCONF implementation in GO.
Recommend the NSO and the terraform provider for NSO to leverage orchestration with NETCONF
Hi and thank you for the quick response.
NETCONF is not a good fit for Terraform as it relies on a two stage commit process. In Terraform there is no concept of doing a "final" operation (like a commit) after applying all resources, so we would need do a commit for each and every resource separately. Also, I am not aware of any actively maintained NETCONF implementation in GO.
I understand your points, but I think there are some mitigations:
I agree that having a commit phase is not convenient, but there are 2 common ways to do it in my knowledge:
- Out-of-band Commit (e.g. Palo Alto)
- Using the depends_on.
We can put all the project in a terraform module and have the commit resource depends on the module.
Also, I assume that RESTCONF will also do a commit behind the hood, so I don't think that it would be much of an issue to automatically commit in each resource under-the-hood.
For the library, I did not realize that you were using an external library. I took a look at go-netascode and it contains like 800 lines. I think having a netconf wrapper similar to this library wouldn't be a lot of work.
But the team is not willing to go in this direction I guess ?
For the library, I did not realize that you were using an external library. I took a look at go-netascode and it contains like 800 lines. I think having a netconf wrapper similar to this library wouldn't be a lot of work.
Unfortunately, it is not. This would be a lot more complex. For example the guy maintaining the junos TF provider is also maintaining its own fork of the Juniper NETCONF implementation -> github.com/jeremmfr/go-netconf.
What would be the benefit for the user if we would use NETCONF? I don't think device/os compatibility is an issue as RESTCONF is supported on every current device/os. In fact, initially I was considering using gNMI (which I am using for XR) which has an even simpler interface, but then chose to go with RESTCONF because of device/os compatibility.