Hi all, Nova currently allows us to filter instances by fixed IP address(es). This feature is known to be useful in an operational scenario that cloud administrators detect abnormal traffic in an IP address and want to trace down to the instance that this IP address belongs to. This feature works well except a limitation that it only supports fixed IP address(es). In the real operational scenarios, cloud administrators might find that the abused IP address is a floating IP and want to do the filtering in the same way as fixed IP.
Right now, unfortunately, the experience is diverged between these two classes of IP address. Cloud administrators need to deploy the logic to (i) detect the class of IP address (fixed or floating), (ii) use nova's IP filter if the address is a fixed IP address, (iii) do manual filtering if the address is a floating IP address. I wonder if nova team is willing to accept an enhancement that makes the IP filter support both. Optimally, cloud administrators can simply pass the abused IP address to nova and nova will handle the heterogeneity. In term of implementation, I expect the change is small. After this patch [1], Nova will query Neutron to compile a list of ports' device_ids (device_id is equal to the uuid of the instance to which the port binds) and use the device_ids to query the instances. If Neutron returns an empty list, Nova can give a second try to query Neutron for floating IPs. There is a RFE [2] and POC [3] for proposing to add a device_id attribute to the floating IP API resource. Nova can leverage this attribute to compile a list of instances uuids and use it as filter on listing the instances. If this feature is implemented, will it benefit the general community? Finally, I also wonder how others are tackling a similar problem. Appreciate your feedback. [1] https://review.openstack.org/#/c/525505/ [2] https://bugs.launchpad.net/neutron/+bug/1723026 [3] https://review.openstack.org/#/c/534882/ Best regards, Hongbin
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
