API Problems: SDN availability

[Malte513]

Hi,
I'm not 100% sure if it is a bug or if I'm misunderstanding something about the API.
If I check the status of an VXLAN zone via api2/json/nodes/{node}/sdn/zones it shows me that the zone is available for all nodes, but /api2/json/cluster/resources shows that the zone is still pending on some nodes.
If the zone is available via api2/json/nodes/{node}/sdn/zones, vnets and VMs can be created. But to start VMs, the zone seemingly needs to be available via /api2/json/cluster/resources.
So when I check for availability of the zone and vnet via api2/json/nodes/{node}/sdn/zones and /api2/json/nodes/{node}/sdn/zones/{zone}/content, and i automatically create and start my VMs, as soon as they return available for all nodes, I sometimes receive a TASK ERROR: bridge 'vnet name' does not exist , when the VM gets started.

Is this expected behaviour or a bug?

 

[shanreich]

There is a distinction between the SDN configuration and the running configuration (which you can get via providing the running GET parameter) on the zones endpoint. You need to apply changes to the SDN configuration on the nodes (hence why some objects still have status pending).

 

[Malte513]

The /api2/json/cluster/sdn/zones endpoint returns the same data for the running and pending configuration:
{"ipam": "pve", "peers": "ip addresses", "zone": "Zone Name", "type": "vxlan", "digest": null}. The same happens with the vnet endpoint.
I'm not sure how this information can help me determine if the vnets in the zone are ready to be used.
The /api2/json/cluster/resources endpoint seems to be the only way to reliably get this information.

P.S: I apply the changes via /api2/json/cluster/sdn, and then check the other endpoints to determine if the changes are applied on all nodes.

 

[shanreich]

The /api2/json/cluster/sdn/zones endpoint returns the same data for the running and pending configuration:
{"ipam": "pve", "peers": "ip addresses", "zone": "Zone Name", "type": "vxlan", "digest": null}. The same happens with the vnet endpoint.

Interesting, it might be a race condition where that endpoint returns the new configuration immediately after applying the new configuration, but it is still in the process of being applied.