-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check openflow(OF) rules on each hyperviors after binding lports #102
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -38,6 +38,7 @@ def _create_lswitches(self, lswitch_create_args): | |
|
||
print("create lswitch") | ||
self.RESOURCE_NAME_FORMAT = "lswitch_XXXXXX_XXXXXX" | ||
self.port_mac = dict() | ||
|
||
amount = lswitch_create_args.get("amount", 1) | ||
batch = lswitch_create_args.get("batch", amount) | ||
|
@@ -124,6 +125,7 @@ def _create_lports(self, lswitch, lport_create_args = [], lport_amount=1): | |
ovn_nbctl.enable_batch_mode() | ||
|
||
base_mac = [i[:2] for i in self.task["uuid"].split('-')] | ||
base_mac[0] = str(hex(int(base_mac[0], 16) & 254)) | ||
base_mac[3:] = ['00']*3 | ||
|
||
|
||
|
@@ -138,6 +140,7 @@ def _create_lports(self, lswitch, lport_create_args = [], lport_amount=1): | |
|
||
ovn_nbctl.lport_set_addresses(name, [mac, ip]) | ||
ovn_nbctl.lport_set_port_security(name, mac) | ||
self.port_mac[name] = mac | ||
|
||
lports.append(lport) | ||
|
||
|
@@ -251,6 +254,43 @@ def _create_networks(self, network_create_args): | |
return lswitches | ||
|
||
|
||
@atomic.action_timer("ovn_network.of_check_port") | ||
def _of_check_ports(self, lports, sandboxes, port_bind_args): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you write some comments about why, what and how is it checked? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why? In our OVN scalability test with dataplane (NOTE: not ovn-scale-test/sandbox), we found that some lport is not pingable after binding. After certain time period, the lport becomes pingable. One suspicious point is that the openflow rules after binding is not setup fast enough. Therefore checking "port state up" is insufficient. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I understand correctly, the purpose is to evaluate the end-to-end time spent in port-binding and flow installation in HVs, right? Yes, checking "port state up" is insufficient. But there are problems of checking flows on HVs:
Because of this, we need a notification mechanism to accurately evaluate when all the HVs have finished processing the port-binding. It is handled by [1]. I believe it is a better approach, but I haven't worked on it yet. [1] #97 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @hzhou8 I agreed with both of your points; we should use the
[1] #97 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @huikang For 2): I wonder if it is really needed to check correctness of flows in scale test. IMHO the focus here is the performance, and OVN functional tests should ensure correctness (the tests under OVS repo, and also openstack networking-ovn etc.). If we do suspect some scalability related bug, it may be helpful to have such kind of check AFTER the scale test complete. If we decide to implement such checks, we should make sure those checks won't impact the performance data. Instead of a separate thread running in parallel, I'd prefer a post-test validation. It should not be enabled by default because it would take too long considering the number of ports in scale test, and only enabled when we are testing correctness. Priority should not be high, though. What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @hzhou8 Thanks for your response.
|
||
port_bind_args = port_bind_args or {} | ||
wait_up = port_bind_args.get("wait_up", False) | ||
|
||
sandbox_num = len(sandboxes) | ||
lport_num = len(lports) | ||
lport_per_sandbox = (lport_num + sandbox_num - 1) / sandbox_num | ||
|
||
LOG.info("Checking OF lports method: %s" % self.install_method) | ||
install_method = self.install_method | ||
|
||
j = 0 | ||
for i in range(0, len(lports), lport_per_sandbox): | ||
lport_slice = lports[i:i+lport_per_sandbox] | ||
|
||
sandbox = sandboxes[j]["name"] | ||
farm = sandboxes[j]["farm"] | ||
ovs_vsctl = self.farm_clients(farm, "ovs-vsctl") | ||
ovs_vsctl.set_sandbox(sandbox, install_method) | ||
ovs_vsctl.enable_batch_mode() | ||
|
||
for lport in lport_slice: | ||
port_name = lport["name"] | ||
|
||
LOG.info("of check %s to %s on %s" % (port_name, sandbox, farm)) | ||
|
||
# check if OF rules installed correctly | ||
mac_addr = self.port_mac[port_name] | ||
of_check = ovs_vsctl.of_check('br-int', port_name, mac_addr) | ||
if of_check is False: | ||
LOG.info("Return false" ) | ||
raise exceptions.NotFoundException(message="openflow rule") | ||
|
||
ovs_vsctl.flush() | ||
j += 1 | ||
|
||
|
||
@atomic.action_timer("ovn_network.bind_port") | ||
def _bind_ports(self, lports, sandboxes, port_bind_args): | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the purpose is to verify the binding operation finished and reflected in flows, how about simply: ofctl dump-flows br-int table=| grep
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hzhou8 thanks for reviewing the PR. You are right; binding operation could be verified by
ofctl dump-flow
. However, IMO, tracing a flow, which is used OVN tutorial, seems more accurate and straightforward.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the flow trace seems too heavy and subject to change in the future. For example, when there are ACL rules, the programmed flows can also result in a drop action. So I think dump-flow for the ARP table is straightforward and simple. And less operations, e.g. no need to find out the ofport first.