Questions about go-netbox/v3 (openapi)

[smutel]

Hello,

Thanks for the job done to change this library to use openapi.

I have several questions:

• Could we have an example how to add an object in Netbox ? We have some example to list objects but not to create one.
• How to pass insecure option (to not check TLS cert) to NewConfiguration() ?

Thanks.

[jqueuniet]

I posted a creation example earlier in the OpenAPI discussion, but here it is for convenience:

// Create an IP address
req := netbox.WritableIPAddressRequest{
	Address: address,
}
req.SetTenant(tenant.Id)
req.SetStatus("active")
if vrf != nil {
	req.SetVrf(vrf.Id)
}

ipAddress, resp, err := client.
	IpamApi.
	IpamIpAddressesCreate(ctx).
	WritableIPAddressRequest(req).
	Execute()

Here is another for a VM interface with slightly different calls:

req := netbox.NewWritableVMInterfaceRequestWithDefaults()
req.SetName(fmt.Sprintf("net%d", vif.Index))
req.SetVirtualMachine(vm.Id)

if vif.MTU != 0 {
	req.SetMtu(vif.MTU)
}

nbvif, resp, err := client.
	VirtualizationAPI.
	VirtualizationInterfacesCreate(ctx).
	WritableVMInterfaceRequest(*req).
	Execute()

Skipping TLS certificate validation is done by tweaking the http.Client in the usual manner:

configuration := netbox.NewConfiguration()
configuration.HTTPClient = &http.Client{
	Transport: &http.Transport{
		TLSClientConfig: &tls.Config{
			InsecureSkipVerify: true,
		},
	},
}

apiClient = netbox.NewAPIClient(configuration)

[jacobsalmela]

Yes, issue #165 is a deserialization bug, at best the resource recovered will be an unititialized struct, at worst a nil pointer, and in both cases is unlikely to be of any use. Until the library is fixed, the only workaround I can see is to write your own deserialization using the response.Body content.

Does it need to be fixed in netbox itself or the openapi code to generate the library?

Ran into this on creating device types with this library.

[jqueuniet]

I took some time to dig into it this morning and found what seems to be a similar bug on the Netbox project: netbox-community/netbox#14953

So the fact those fields are required seems intended and their absence seems to be a bug.

This could be worked around by editing the OpenAPI spec before generating the library code in the meantime, at least until Netbox solves the issue on their side.

[smutel]

What do you to add something like this in these project:

• https://github.com/smutel/go-netbox/tree/main/patchs
• https://github.com/smutel/go-netbox/blob/59bcec29858a60e9e27a698ed13182425a2ae269/utils/netbox_generate_client#L75

The generated patch can be used until the issue is completely fixed in Netbox project which could be more or less long to have. This avoid to keep an issue in this project because the issue is still in the Netbox project.

[jqueuniet]

There's already a process to patch the spec, using the scripts/fix-spec.py. Given it basically reserializes the whole spec file, I'm not sure using a text-based workflow with patch is going to work very well with it, or it would have to be applied first, probably using a separate bash script. I guess it does use the same PyYAML parser as upstream though, so maybe it doesn't change things too much.

YAML tree manipulations do have the advantage of allowing complex workflows and being a lot more resistant to minor changes from upstream. As this Netbox bug probably affects other endpoints than the one talked about here given the upstream issue comments, maybe iterating over all responses and turning optional every root field with *_count would be a more comprehensive solution.

Feel free to open a PR either way, though I'm not a maintainer here, just answering what question I can since I've spent a fair amount of time dealing with OpenAPI generator-based Go clients at this point.

[smutel]

Only some of them, I haven't had any issue on IPAM endpoints this far, but did found a similar issue in DCIM and virtualization.

For now, quite all DCIM objects have the same issues ... 😭
https://github.com/smutel/terraform-provider-netbox/blob/UpdateForNetbox3.7/tmp/README.md