ML2 context not considering tags at network creation and update

Bug #2018009 reported by Juan Pablo Suazo
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Confirmed
Medium
Miro Tomaska

Bug Description

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.

Changed in neutron:
assignee: nobody → Juan Pablo Suazo (jsuazo)
Changed in neutron:
importance: Undecided → Medium
description: updated
Revision history for this message
Miro Tomaska (mtomaska) wrote :

Hi Juan.

You have assigned this bug to yourself, I am assuming you want to look into it?

Thanks

Revision history for this message
Juan Pablo Suazo (jsuazo) wrote :

Hi Miro,

Sorry, force of habit when generating proposals, didn't mean to assign myself.

I have tried to determine the origin of this bug but I'm not familiar enough with the code to do so yet.

It would be of great help if someone from neutron side could aid determining what is happening here.

Changed in neutron:
assignee: Juan Pablo Suazo (jsuazo) → nobody
Miro Tomaska (mtomaska)
Changed in neutron:
assignee: nobody → Miro Tomaska (mtomaska)
Revision history for this message
Miro Tomaska (mtomaska) wrote :

Just by a quick look I think this is by design but I will confirm. Tags in neutron are handled by the tag service[1] and their are not intended to be used by mechanism drivers to pass information.

[1]
https://docs.openstack.org/neutron/ocata/devref/tag.html
https://github.com/openstack/neutron/blob/master/neutron/services/tag/tag_plugin.py

Revision history for this message
Rodolfo Alonso (rodolfo-alonso-hernandez) wrote :

Hello:

The issue seems to be in the OSC client. The network creation method is calling "_get_attrs_network" [1]. This method is not parsing "tags" from the arguments ("tags" is present in the "parsed_args" Namespace object). The "attrs" dictionary returned doesn't contain the tags provided by the user.

NOTE: this bug could be present in other Neutron resources that could be tagged. This resource map, extracted from "neutron.services.tag.tag_plugin:resource_model_map is [2].

Regards.

[1]https://github.com/openstack/python-openstackclient/blob/43f0e1090a201921dc7fa29bfd7a3594391214cb/openstackclient/network/v2/network.py#L77
[2]https://paste.opendev.org/show/bofZrp7xwcWHbP7A3M1d/

Revision history for this message
Juan Pablo Suazo (jsuazo) wrote :

Hi,

Looking at the code Rodolfo pointed out, it seems a fix would require minimal changes and it should be developed fairly quickly. From our part,, we can take responsibility of the development and proposal.

I'm still unclear if this is a bug or an expected behaviour as Miro suggested. Could you please confirm this info and give us a green light to start working on a proposal.

Revision history for this message
Miro Tomaska (mtomaska) wrote :

Rodolfo is the core reviewer so I would go with what he said(its a bug). I was just going off what I have read in the doc I linked above and my personal conclusion looking at the code.

Revision history for this message
Miro Tomaska (mtomaska) wrote :

I have played with this a little and I think the problem is that tagging an object is two step process.

When you create an object (e.i. network) POST with a tag, the tag is followed by a later PUT call. I.e. PUT /networking/v2.0/networks/<network_uuid>/tags

you can see that output by appending --debug argument.

E.I. `openstack network create --tag test_tag test_network --debug`

There is also comment in the python-openstack repo [1] but I wish it gave more explanation for "why not?".

Even if I enable "tag" parsing[2] and allow POST[3] for tagging the context object will not contain the tag value.

[1] https://codesearch.openstack.org/?q=tags%20cannot%20be%20set%20when%20created%2C%20so%20tags%20need%20to%20be%20set%20later&i=nope&literal=nope&files=&excludeFiles=&repos=openstack/python-openstackclient
[2] https://github.com/openstack/python-openstackclient/blob/43f0e1090a201921dc7fa29bfd7a3594391214cb/openstackclient/network/v2/network.py#L77
[3] https://opendev.org/openstack/neutron/src/commit/940a1b6cea0ca92e59a50af57417cd2820c8d27b/neutron/extensions/tagging.py#L43

Miro Tomaska (mtomaska)
Changed in neutron:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.