+ def set_interface_details(self, devices, net_mac, net_type, req_net_type, virt_type): + if net_type != req_net_type: + interface = self.add_sub_node(devices, 'interface', type=req_net_type) + else: + interface = self.add_sub_node(devices, 'interface', type=net_type)
I'm not sure I understand the need for two net_type parameters here. No matter what the value of net_type is, you're always setting the value of the interface to req_net_type. In the case of the RAFP test, the test was assuming that all guests had a network device that belonged to a specific pool. So for that test case, creating a guest with an ethernet interface would not be valid. However, you could have situations where you'd want to verify that the providers are properly managing a guest that doesn't have a network type. One such example would be to verify that adding a new ethernet resource to a Xen guest with an ethernet interface is successful. Even though we don't create guests with ethernet devices, we should still be able to manage them. So, I like the idea of being able to specify the network type. I think the req_net_type parameter is unnecessary here.
+ self.add_sub_node(interface, 'mac', address=net_mac) + if req_net_type == 'bridge': + self._set_vbridge(CIM_IP, virt_type) + elif req_net_type == 'network': + self.set_vnetwork(interface, virt_type) + elif req_net_type == 'ethernet': + pass
You'll also want to support the "user" network type for KVM since NetworkPort/03_user_netport.py uses it. The user network type is only valid for KVM, so you wouldn't want to be able to create Xen guests of this type.
+ else: + logger.error("%s is not a valid network type", net_type) + sys.exit(1)
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com