The test class was not inheriting from testlib_api.SqlTestCase which
means that the test cases were never executed.
Once it was executed, it became obvious that the object has an issue
with SQL query scalability. Specifically, it was failing the
test_get_objects_queries_constant test case that validates that the
number of queries to fetch a single object is the same as for multiple
objects. This happens because PortBindingLevel's 'segment' synthetic
field is not constructed from db model relationship but through issuing
a get_object OVO call that triggers a query per fetched PortBindingLevel
object.
To fix the issue, the patch added a new 'segment' relationship to
PortBindingLevel db model, and made OVO use attributes from the
relationship to construct 'segment' synthetic field.
Another issue revealed by enabling the test class is that foreign_key
definition for the 'segment' synthetic field located in NetworkSegment
object refers to 'segment_id' field but the field with this name is not
defined on PortBindingLevel object. The easiest thing we can do to
resolve the discrepancy is adding the 'segment_id' UUID typed field to
PortBindingLevel, which is what the patch does. (An alternative could be
hacking our way around the lack of the field, building another layer of
complexity in the base OVO class for this special case; I figured it's
probably counterproductive, and we can live with 'segment_id' field even
though it's arguably somewhat redundant - 'segment' object field already
carries the ID.)
Adding a new field to PortBindingLevel object means that we need to bump
its version, as well as versions of all objects that use the newly
modified field type for their own fields. The only object that refers to
the type is Port. That's why we also bump the version of Port object.
To make older agents that use RPC callbacks work with the change, we
also provide corresponding obj_make_compatible methods for both Port and
PortBindingLevel objects.
Change-Id: I1ec56c57f87218520c2080c0b3450f1eabc13224
b74af5ff65