Internally, our company has developed a ML2 plugin which is used to implement the `post_commit` functions for network, subnetwork and port creation, updating and deletion. The plugin then sends requests to our SDN product, which configures an integrated switch to match the network topology.
Recently, we aimed to extend our SDN support to Border Leafs, which meant indicating the VRF to be used in the BLs. Our implementation considered adding a tag to the provider network to be configured with the BLs, indication the VRF id ("vrf-<ID>"), and using that value in our requests to our SDN.
The problem we encountered is that, when creating networks with tags or updating tags, the context used passed to the create_network_precommit and create_network_postcommit functions does not include the created tags. For example:
:~$ openstack network create --share --provider-physical-network physnet1 --provider-network-type vlan --provider-segment 26 --tag vrf-test-tag PUBLIC-tag
shows the following logs:
2023-04-26 19:51:01.391 23 DEBUG neutron.plugins.ml2.drivers.whitesdn [req-b742fcea-a276-4f36-90a0-2a5574ea7d6f 80bb7b73308440cfa9d314b5469062bb 9635877c16724a9da060d122b49a0fd5 - default default] Debugging WhiteSdn data for method: create_network _log_method
/var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/whitesdn.py:138
2023-04-26 19:51:01.392 23 DEBUG neutron.plugins.ml2.drivers.whitesdn [req-b742fcea-a276-4f36-90a0-2a5574ea7d6f 80bb7b73308440cfa9d314b5469062bb 9635877c16724a9da060d122b49a0fd5 - default default] WhiteSdn current context: {'id': '1f9f11e8-2416-4ead-8133-c9d3469f352e', 'name': 'PUBLIC-tag', 'tenant_id': '9635877c16724a9da060d122b49a0fd5', 'admin_state_up': True, 'mtu': 1300, 'status': 'ACTIVE', 'subnets': [], 'shared': True, 'project_id': '9635877c16724a9da060d122b49a0fd5', 'port_security_enabled': True, 'router:external': False, 'provider:network_type': 'vlan', 'provider:physical_network': 'physnet1', 'provider:segmentation_id': 26, 'availability_zone_hints': [], 'is_default': False, 'availability_zones': [], 'ipv4_address_scope': None, 'ipv6_address_scope': None, 'vlan_transparent': None, 'description': '', 'tags': [], 'created_at': '2023-04-26T19:51:01Z', 'updated_at': '2023-04-26T19:51:01Z', 'revision_number': 1} _log_method /var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/whitesdn.py:139
Where you can see that the 'tags' field is empty. Additionally, no update functions are triggered when updating the tags, the following commando generates no logs:
openstack network set --tag vrf 1f9f11e8-2416-4ead-8133-c9d3469f352e
The strange part is that if you posteriorly update another attribute of the network, or delete it, the tag does come inside the context:
openstack network set --description "Hello, World!" 1f9f11e8-2416-4ead-8133-c9d3469f352e
2023-04-26 20:04:08.652 23 DEBUG neutron.plugins.ml2.drivers.whitesdn [req-d7537944-757e-46e7-8456-28416655ff9d 80bb7b73308440cfa9d314b5469062bb 9635877c16724a9da060d122b49a0fd5 - default default] Debugging WhiteSdn data for method: update_network _log_method /var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/whitesdn.py:138
2023-04-26 20:04:08.653 23 DEBUG neutron.plugins.ml2.drivers.whitesdn [req-d7537944-757e-46e7-8456-28416655ff9d 80bb7b73308440cfa9d314b5469062bb 9635877c16724a9da060d122b49a0fd5 - default default] WhiteSdn current context: {'id': '1f9f11e8-2416-4ead-8133-c9d3469f352e', 'name': 'PUBLIC-tag', 'tenant_id': '9635877c16724a9da060d122b49a0fd5', 'admin_state_up': True, 'mtu': 1300, 'status': 'ACTIVE', 'subnets': [], 'shared': True, 'availability_zone_hints': [], 'availability_zones': [], 'ipv4_address_scope': None, 'ipv6_address_scope': None, 'router:external': False, 'vlan_transparent': None, 'description': 'Hello, World!', 'port_security_enabled': True, 'tags': ['vrf'], 'created_at': '2023-04-26T19:51:01Z', 'updated_at': '2023-04-26T20:04:08Z', 'revision_number': 6, 'project_id': '9635877c16724a9da060d122b49a0fd5', 'provider:network_type': 'vlan', 'provider:physical_network': 'physnet1', 'provider:segmentation_id': 26} _log_method /var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/whitesdn.py:139
openstack network delete PUBLIC-tag
2023-04-26 19:35:15.455 24 DEBUG neutron.plugins.ml2.drivers.whitesdn [req-78a6c31f-95ef-4563-a10d-efd96d51e4d3 80bb7b73308440cfa9d314b5469062bb 9635877c16724a9da060d122b49a0fd5 - default default] Debugging WhiteSdn data for method: delete_network _log_method /var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/whitesdn.py:138
2023-04-26 19:35:15.456 24 DEBUG neutron.plugins.ml2.drivers.whitesdn [req-78a6c31f-95ef-4563-a10d-efd96d51e4d3 80bb7b73308440cfa9d314b5469062bb 9635877c16724a9da060d122b49a0fd5 - default default] WhiteSdn current context: {'id': '1f9f11e8-2416-4ead-8133-c9d3469f352e', 'name': 'PUBLIC-tag', 'tenant_id': '9635877c16724a9da060d122b49a0fd5', 'admin_state_up': True, 'mtu': 1300, 'status': 'ACTIVE', 'subnets': [], 'shared': True, 'availability_zone_hints': [], 'availability_zones': [], 'ipv4_address_scope': None, 'ipv6_address_scope': None, 'router:external': False, 'vlan_transparent': None, 'description': 'Hello, World!', 'port_security_enabled': True, 'tags': ['vrf'], 'created_at': '2023-04-26T19:32:50Z', 'updated_at': '2023-04-26T19:32:51Z', 'revision_number': 2, 'project_id': '9635877c16724a9da060d122b49a0fd5', 'provider:network_type': 'vlan', 'provider:physical_network': 'physnet1', 'provider:segmentation_id': 26} _log_method /var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/whitesdn.py:139
The inconsistent manner in which tags are included in the context leads us to believe this is a bug in neutron ML2. All this has been developed and tested in openstack Xena.
This is a blocking bug for us as it prevent us implementing our solution.
Hi Juan.
You have assigned this bug to yourself, I am assuming you want to look into it?
Thanks