Hi Mauricio,
I have uploaded a new debdiff to delivery your comment, I use the
verison 2:20.5.0-0ubuntu2.1 and add DEP-3 headers now. As for the 'Test
Case' section, I have been trying to find a reproducer for the past two
weeks, but all attempts have failed, it's quite difficult to reproduce
the behavior that ovsdb will merge insert and update notifications.
The essence of this fix patch is to address the problem through a retry
mechanism.
Without this fix patch:
1, MetadataAgent#start call sync, then call provision_datapath to trigger the
initial creation of metadata namespace.
2, only ROW_UPDATE event in PortBindingChassisCreatedEvent can trigger
provision_datapath the second time.
3, no more ROW_UPDATE event in PortBindingChassisCreatedEvent can trigger
provision_datapath the third time due to the comment [2] (and not old.chassis).
class PortBindingChassisCreatedEvent(PortBindingChassisEvent):
def init(self, metadata_agent):
events = (self.ROW_UPDATE,)
super(PortBindingChassisCreatedEvent, self).init(metadata_agent, events)
def match_fn(self, event, row, old):
return (row.chassis[0].name == self.agent.chassis and not old.chassis)
As said in comment[2]:
What this means is that our PortBindingUpdatedEvent (or
PortBindingChassisCreatedEvent) which looks for "update" events don't
fire when we get a Port_Binding "create" that has the chassis field set.
Yes, that's because match_fn includes the condition 'not old.chassis',
1, openstack port create --network private --fixed-ip subnet=private_subnet
$PORT_NAME
When creating a port, we can see an insert event via 'ovsdb monitor', but
nothing from the neutron-metadata-agent log since
PortBindingChassisCreatedEvent doesn't monitor ROW_INSERT
2, openstack server add port cirros-0.4.0-054427 $PORT_NAME
When adding a port to a VM, we can see an update event via 'ovsdb monitor' and
logs from neutron-metadata-agent log as well because it meets the condition
(row.chassis[0].name == self.agent.chassis and not old.chassis)
3, openstack port set $PORT_NAME --fixed-ip
subnet=private_subnet,ip-address=192.168.21.$((RANDOM % 255 + 1))
When updating a port's IP, we can see an update event via 'ovsdb monitor', but
nothing from neutron-metadata-agent log because it doesn't meet the condition
(and not old.chassis)
In other words, the current condition (ROW_UPDATE and
row.chassis[0].name == self.agent.chassis and not old.chassis) only
gives provision_datapath one chance to run. if an issue occurs with
ovsdb at this time, subsequent ovsdb update events like above step 3
will not give provision_datapath another change to run.
The current fix patch [1] changes the condtion from
ROW_UPDATE and row.chassis[0].name == self.agent.chassis and not
old.chassis
to
(ROW_INSERT or ROW_UPDATE) and row.chassis[0].name == self.agent.chassis
and not old.chassis
Thus, now provision_datapath has two chances to run, making this patch
act as a retry mechanism, and of course it can solve the problem.
Anyway, since I cannot reproduce the problem, I can only theretically
say that this patch can solve the problem as mentioned above. Even if it
cannot solve the problem, it is theretically harmess, and we have also
ensured it through charmed-openstack-tester. I hope these can help.
thanks a lot.
[1] https://review.opendev.org/c/openstack/neutron/+/926656
[2] https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/2017748/comments/6
** Changed in: neutron (Ubuntu Jammy)
Status: Incomplete => In Progress
** Changed in: neutron (Ubuntu Focal)
Status: Won't Fix => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2017748
Title:
[SRU] OVN: ovnmeta namespaces missing during scalability test causing
DHCP issues
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2017748/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
