dcd78423aa
Those objects are intentionally not integrated into the database code so far. This is to quicken access to their definitions to implement push-notifications for security groups and ports. The object embeds segmentation information in addition to what's available through the model. Specifically, binding_levels field exposes all ml2 binding levels, that from their side load corresponding network segment object. The order for level objects in binding_levels list field is guaranteed to be in the order of level. So the consumers can eg. access the bottom binding info with: port_obj.binding_levels[-1].segment For PortBindingLevel object, we want to expose segmentation info. This is achieved through a 'segment' ObjectField. The database model itself contains segment_id too. There is no reason though to expose it for Level object in two places (one as a model field, another one through the ObjectField), so we avoid adding ID field. The base class that handles loading for ObjectField based synthetic fields was assuming that objects always have a field per model attribute, so it needed a slight adjustment to support this case, where we extract foreign_keys attributes from the model itself if the field is not present on the object. Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db Partially-Implements: blueprint push-notifications Change-Id: I25de14e42e345d9235dbf4097c298ef5d606de51 Co-Authored-By: Martin Hickey <martin.hickey@ie.ibm.com> Co-Authored-By: Rossella Sblendido <rsblendido@suse.com> Co-Authored-By: Manjeet Singh Bhatia <manjeet.s.bhatia@intel.com> Co-Authored-By: Brandon Logan <brandon.logan@rackspace.com> Co-Authored-By: Victor Morales <victor.morales@intel.com> |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| test_api.py | ||