[regression] Unable to schedule segment

[Sahid Orentino]

The fix proposed to address https://bugs.launchpad.net/neutron/+bug/1952730 is creating regression. It is not possible to schedule segments as the change is checking a configuration change inside the agent to quick-pass on the rest of the process.

Just attach a segment to a subnet to reproduce the case.

The workaround is to change something in the configuration file of the agent let’s say by incrementing a vlan range and restarting the agent.

[Bence Romsics (bence-romsics)]

Hi Sahid,

Could you please give exact commands that reproduce the issue?

I remember that we were thinking about possibly shortcutting some updates:
https://review.opendev.org/c/openstack/neutron/+/819777/comments/cf0486f6_bc0a1ee5

But apparently we missed something...

Thanks,
Bence

[Sahid Orentino (sahid-ferdjaoui)]

Hello Bence,

From any deployment using:

  openstack subnet set --network-segment {segment} {subnet}

You can notify that the table segmenthostmappings is not updated, also the aggregate related.

Thanks looking at it,
s.

[Bence Romsics (bence-romsics)]

Hi Sahid,

Sorry for the slow answer.

I did some testing with 'openstack subnet set --network-segment' right after this ticket was opened and now some more and I still don't seem to be able to reproduce the bug reported here. I tried two scenarios:

1)
mysql neutron <<<"select * from segmenthostmappings" | column -t # empty
openstack net create net0
# rename the implicitly created vxlan segment for ease of reference
openstack network segment set $( openstack network segment list --network net0 -f value -c ID ) --name net0-segment0
openstack subnet create subnet0 --subnet-range 10.0.4.0/24 --network net0
openstack subnet show subnet0 -f value -c segment_id # None
openstack subnet set subnet0 --network-segment net0-segment0
openstack subnet show subnet0 -f value -c segment_id # some uuid
mysql neutron <<<"select * from segmenthostmappings" | column -t # still empty

2)
mysql neutron <<<"select * from segmenthostmappings" | column -t # empty
openstack net create net0
# rename the implicitly created vxlan segment for ease of reference
openstack network segment set $( openstack network segment list --network net0 -f value -c ID ) --name net0-segment0
openstack subnet create subnet0 --subnet-range 10.0.4.0/24 --network net0 --network-segment net0-segment0
openstack network segment create net0-segment1 --network net0 --network-type vlan --physical-network public --segment 200
openstack subnet create subnet1 --network net0 --subnet-range 10.0.5.0/24 --network-segment net0-segment1
mysql neutron <<<"select * from segmenthostmappings" | column -t # net0-segment1 is present

This behavior seems correct to me. I expected the vlan and flat segments to appear in the segmenthostmappings table - and they did. I did not expect vxlan (on any other tunneling) segments to appear there. But let me know if you think differently.

Also I tested these two scenarios with two neutron versions:
a) current master: 2a44898119
b) current master: 2a44898119 + revert of 176503e610 on top

And I see no behavior change between the two.

Do I misunderstand something in the report?

In order two work with this bug report can you please tell us:

* what exactly are you doing (commands, outputs, db table contents)
* what is the behavior you expect
* what is happening instead

Thanks:
Bence

[Sahid Orentino (sahid-ferdjaoui)]

Hey Bence, sorry for this late reply. The problem is when using network provider, related to the physnet. Since the agent is doing update only if the configuration file (ml2.conf) is updated, if you change anything (I have to remember what...) related the segment attached to the phynet, nothing will be updated.

The workaround was to update the configuration file by incrementing for example the vlan_range per 1, then the server would have well updated the segment as server will see a change is conf

I will try to build real reproducer for it