https://github.com/ovn-org/libovsdb/blob/e29d8bd57b4a0590ec63a622e2c2f2533e274db6/model/model.go#L78

This should probably logged as a warning (at most) and the table should optionally be removed from the model. Otherwise it breaks all upgrade scenarios in which clients are upgraded before the database. Even worse, the client might have an external way of checking if a table actually exists on the remote server (e.g., run an ovn-nbctl list <table> command), and adapt its execution based on that information, completely avoiding to use the nonexistent table.

An example of such a scenario can be found here; the client fails to validate the schema every time it connects to a remote server, crash loops, even though it's perfectly able to function when the table is missing on the server side:

F1004 16:31:22.456301      34 ovnkube.go:131] error when trying to initialize libovsdb NB client: failed to connect to tcp:172.18.0.3:6641: database OVN_Northbound validation error (3): Mapper Error. Object type nbdb.LogicalRouter contains field LoadBalancerGroup ([]string) ovs tag load_balancer_group: Column does not exist in schema. database model contains a model for table Load_Balancer_Group that does not exist in schema. Mapper Error. Object type nbdb.LogicalSwitch contains field LoadBalancerGroup ([]string) ovs tag load_balancer_group: Column does not exist in schema

CC: @amorenoz