Networking improvements #12
Description
For oneview harware type at Ironic and networking-oneview ML2 plugin.
VLAN-aware bare metal instances
For OneView scenarios it is expected that Neutron is responsible for tagging outgoing traffic and untagging incoming traffic to bare metal instances for multi-tenancy scenarios using VLAN (with networking-oneview ML2 plugin). Can the instance be VLAN-aware and start being responsible for this tasks without affecting the connections creation process at OneView? From the community perspective, the vlan-aware bare metal instance specification was abandoned in favour of using Neutron trunk ports to support this functionality.
Delaying network creation in OneView until port creation
Latest implementation of networking-oneview allocates OneView resources (VLAN IDs in UplinkSets, for example) when creating networks. Can we take advantage of the infrastructure by late binding the network resources only when the first connection using it is about to be created in the Server Profile? Remembering that networking-oneview checks for existent networks with the same VLAN ID on the LIG/LI's uplinkset when creating networks; this feature needs to be in sync with this kind of checking.
Hierarchical port binding with TOR switch (needs TOR switch driver)
By having implemented the feature above (delaying network creation), can we also delay the allocation of network resources on top-of-rack devices? This would also require ML2 drivers for the TOR switches available on the infrastructure to be loaded in parallel with networking-oneview at OpenStack Neutron.
Support port groups -- Link Aggregation Groups
How can OpenStack high-availability models be matched with OneView Link Aggregation Groups for enhancing network connectivity providing load balancing and fail-over?