Trunk: different behavior of admin_state_up attribute between trunk and port

[Le, Huifeng]

High level description:
The behavior of admin_state_up attribute is different between port and trunk which may impact user experience.

Environments: configure neutron to use openvswitch agent
Version: latest devstack

Steps to reproduce:
1. create network/subnet/port
2. update port to set admin_state_up = FALSE (which will set port status to “Down”, then disable the port to block send/receive packages, e.g. set port’s tap device state to down or move the port to DEAD_VLAN etc.)
3. verify the port cannot work
result: the port can not send/receive packages
4. create trunk
5. update trunk to set admin_state_up = FALSE (which will lock the trunk to prevent operations such as adding/removing subports)
6. check whether the trunk is still operational
Expected output: the trunk will stop to process VLAN packets arriving from VM instance
Actual output: the trunk is still operational (e.g. the trunk sub-port can still send/receive packages)

[Armando Migliaccio (armando-migliaccio)]

Hi, thanks for reporting this bug. In reality this is working as intended. the Trunk admin status is simply a locking mechanism for management operations on the trunk as it's been articulated on the documentation:

https://docs.openstack.org/neutron/pike/admin/config-trunking.html

In particular:

When admin_state is set to DOWN, the user is blocked from performing operations on the trunk. admin_state is set by the user and should not be used to monitor the health of the trunk.

[Armando Migliaccio (armando-migliaccio)]

Having said that, I can see the confusion and a different expectation some users may have. Neutron resources admin states are not necessarily used for blocking the datapath (I think another example of that might neutron router floating IP ports, but I am no longer sure).

The reason why this was designed as was mainly simplicity and robustness. Ensuring that the operation of turning up/down the admin status for trunk worked reliably and atomically across all sub-ports in a trunk is not straightforward, therefore in the absence of a strong use case the existing semantic was chosen.

Hope the explanation help!!