The new field 'physical_network' was added to Port in version
1.7, and port creation was moved from the API to the conductor
service in commit 9e3f4121865807294dd3768b095b67eb01ef539e.
This change adds a method can_send_create_port() to the conductor
RPCAPI that allows the caller to determine whether the conductor is able
to create ports. During a rolling upgrade this may return False, and the
API will need to determine whether it is able to create the port locally
as was done previously.
The create_port RPC method was added to support validation of the
physical_network field of ports in portgroups. A port may therefore be
safely created in the API service if it is not a member of a portgroup.
If the port being created is a member of a portgroup, then it cannot be
safely validated by the API service and the request must be rejected.
Change-Id: I8c417cba085f61c3d2ffe1f7e97c64fa85a014cb
Related-Bug: #1666009
Related-Bug: #1526283
In change Ib22753aa6ae0fedce7fb9ecf63f135fda0185c5b the port data model
was updated to include a physical_network field, but this was not
exposed to the user by the REST API. This change exposes the
physical_network field in the REST API.
The port CRUD notification object has been updated to include the
physical_network field.
The API reference and user guide have been updated to include
information about the ports' physical network field.
The API microversion has been bumped to 1.34. During a rolling upgrade
from Ocata when the API service is pinned, the port physical network
field is hidden from API responses, and API requests including the field
are rejected.
Change-Id: I7023a1d6618608c867c31396fa677d3016ca493e
Partial-Bug: #1666009