Invalid documented security group rule protocol "any"
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
In Progress
|
Low
|
Brian Haley |
Bug Description
The Networking API specification v2.0 for security group rule creation[1] states that:
> The string any (or integer 0) means all IP protocols.
However, attempting to create a security group rule with protocol "any" results in a 400 Bad Request:
```
curl -g -i -X POST \
'https:/
-H "Content-Type: application/json" \
-H "X-Auth-Token: valid-token" \
-d '{"security_
HTTP/1.1 400 Bad Request
content-type: application/json
content-length: 450
x-openstack-
date: Thu, 25 Jul 2024 08:11:49 GMT
{"NeutronError": {"type": "SecurityGroupR
```
Tested on RHOSP 17.1, which is based on Wallaby according to its docs[2].
There appear to be multiple ways to create security group rules that apply regardless of the protocol:
- protocol value set to number zero or string zero: `"protocol": 0` `"protocol": "0"`
- protocol value set to null or unset: `"protocol": null`
- protocol value set to the empty string: `"protocol": ""`
I have grouped them by how they conflict. In other words: you can have a security group containing three of these rules (zero, null, empty) that won't conflict with each other at creation.
My questions:
- These three "protocol" values are stored differently. Do they behave exactly the same?
- Is there a preferred way to create a rule that applies to any protocol?
- Is the documentation effectively wrong about the value "any", or am I missing something?
Thank you.
[1]: https:/
[2]: https:/
no longer affects: | ansible-collections-openstack |
description: | updated |
description: | updated |
tags: | added: doc |
tags: | added: low-hanging-fruit |
Changed in neutron: | |
importance: | Undecided → Low |
Changed in neutron: | |
assignee: | nobody → Brian Haley (brian-haley) |
status: | New → Confirmed |
The openstackclient supports the value of 'any' for the protocol, but it changes it to 'None' for the call.
The API supports both None and 0 for the protocol, and I believe the backend implementations should treat them the same.
Although not on the API page, 'ip' is a valid protocol that maps to '0' (essentially all IP* traffic) and should work as well.
So this just looks like a documentation problem as I'm not sure we want to accept 'any' in the API, but if we did can probably add it to IP_PROTOCOL_ NAME_ALIASES.