I spoke to Matt Riedemann today about this. The conclusion from the ML thread http://lists.openstack.org/pipermail/openstack-operators/2017-October/014459.html is that Nova will be happy with Neutron supporting sub-string matching, not full blown regex. POCs have been submitted in Neutron (https://review.openstack.org/#/c/521683) and Nova (https://review.openstack.org/#/c/525505/) with sub-string matching. Tests were conducted (by Huawei) without and with these patches deployed. 2000 VMs and their corresponding ports (1 per instance) were created and then the instances are filtered using a specific ip address:
GET compute/v2.1/servers/details?all_tenants=1&ip=192.168.1.254
Without the POC patches, this query takes 4000ms. With the patches, the time goes down to 400ms. With substring:
GET compute/v2.1/servers/details?all_tenants=1&ip=192.168.1.2
It took 900ms
I spoke to Matt Riedemann today about this. The conclusion from the ML thread http:// lists.openstack .org/pipermail/ openstack- operators/ 2017-October/ 014459. html is that Nova will be happy with Neutron supporting sub-string matching, not full blown regex. POCs have been submitted in Neutron (https:/ /review. openstack. org/#/c/ 521683) and Nova (https:/ /review. openstack. org/#/c/ 525505/) with sub-string matching. Tests were conducted (by Huawei) without and with these patches deployed. 2000 VMs and their corresponding ports (1 per instance) were created and then the instances are filtered using a specific ip address:
GET compute/ v2.1/servers/ details? all_tenants= 1&ip=192. 168.1.254
Without the POC patches, this query takes 4000ms. With the patches, the time goes down to 400ms. With substring:
GET compute/ v2.1/servers/ details? all_tenants= 1&ip=192. 168.1.2
It took 900ms