Isn’t that tricky for a person who is trying to connect ovs to controller? Its like you may or may not see the node in operations based whether or not it succeeds or fails to update.However the ovs would show conencted=true and manager ip, with no data
in operations. :-)
IMO connection received is exclusive event for creating ovsdb node and then registering for callbacks for update. Current implementation seems more logical(to me) than changing it for 1 case of IID creation.
My further 2 cents on iid serialization/deserialization:
In general, IMO this IID serialization and deserialization is a risk. And should be avoided if possible. If a system is running for long period of time and for some reason someone connected disconnected same ovs nodes with diff setting once with IID
passed to it once without. Your config would be looking very out of synch of your operations. On top of that if the apps that are trying to use this data programmatically would most likely fail to take care of such situations.
Also different apps may choose different strategies to generate iids and would be impossible for them to coexist.
So having only one way of creating IIDs would help in longer run. If one wants avoid iid generation while connecting to OVS or creating bridges then we can always expose RPCs for that. However, if one wants to use CONFIG store to configure, then they
have to build appropriate iid.