Today, I spent some time running tempest/tests/compute/security_groups/test_security_group_rules.py (the test case mentioned in the bug description). I ran it in two different devstack instances: one with nova network and the other with neutron. This is the summary of the results:
1) In the instance with nova network: when method test_security_group_rules_create_with_invalid_id attempts to create rules in a security group that doesn't exist and the security group id is a string convertible to an integer, the response is a 404, which is what it expects. When the same method is modified to provide a security group id that is a string not convertible to integer, the response is a 400, and it fails.
2) In the instance with neutron: when method test_security_group_rules_create_with_invalid_id attempts to create rules in a security group that doesn't exist and the security group id is a string convertible to an integer, the response is a 400 and it fails. When the same method is modified to provide a security group id that is a valid uuid, the response is a 404, which is what it expects.
Based on this behavior, I propose that we don't have a bug. When this test provides a security group id in the correct format to the nova api (integer string for nova network, uuid for neutron) the response is the expected 404. Conversely, when this test provides a security group id in an incorrect format, both nova network and neutron return a 400. In my opinion, these are correct behaviors
Today, I spent some time running tempest/ tests/compute/ security_ groups/ test_security_ group_rules. py (the test case mentioned in the bug description). I ran it in two different devstack instances: one with nova network and the other with neutron. This is the summary of the results:
1) In the instance with nova network: when method test_security_ group_rules_ create_ with_invalid_ id attempts to create rules in a security group that doesn't exist and the security group id is a string convertible to an integer, the response is a 404, which is what it expects. When the same method is modified to provide a security group id that is a string not convertible to integer, the response is a 400, and it fails.
2) In the instance with neutron: when method test_security_ group_rules_ create_ with_invalid_ id attempts to create rules in a security group that doesn't exist and the security group id is a string convertible to an integer, the response is a 400 and it fails. When the same method is modified to provide a security group id that is a valid uuid, the response is a 404, which is what it expects.
Based on this behavior, I propose that we don't have a bug. When this test provides a security group id in the correct format to the nova api (integer string for nova network, uuid for neutron) the response is the expected 404. Conversely, when this test provides a security group id in an incorrect format, both nova network and neutron return a 400. In my opinion, these are correct behaviors