Make security-group-rule-create accept "any" protocol

[Masaki Matsushita]

Related Bug: https://bugs.launchpad.net/python-neutronclient/+bug/1469642

When invalid protocol specified in security-group-rule-create, neutron server returns "protocol values [None, 'tcp', 'udp', 'icmp', 'icmpv6'] are supported" as below:

% neutron security-group-rule-create --protocol foo bar
Security group rule protocol foo not supported. Only protocol values [None, 'tcp', 'udp', 'icmp', 'icmpv6'] and integer representations [0 to 255] are supported.

I think "None" to specify any protocols is confusing and inconsistent with FWaaS CLI options (it accepts "any" protocol).

[Masaki Matsushita (mmasaki)]

https://review.openstack.org/197002

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/197002
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Akihiro Motoki (amotoki)]

From API perspective, I think we don't need to have two values which have the same meaning.
What is the difference between None and "any"?
If they mean the same, when the field is unspecified in a create request,
what value should the neutron server return, None or "any"?
If "any" is specified, should we return either of None or "any"?
In the REST principal, a value in a request and a response should match when it is specified in a request.

IMHO, None is widely used to mean unspecified and in a security group rule (or firewal rule) it sounds natural that "unspecified" means "any".

I know there are various opinions on this and suggest to discuss this in the API WG.

CLI option is different. I think it should be more descriptive, so it sounds reasonable to display "any" in the help message.

[Akihiro Motoki (amotoki)]

It seems you are talking about the neutronclient options.
In the FWaaS API, there is no definition in "any".

In neutronclient code (fw/firewallrule.py), there is the following code:

        protocol = parsed_args.protocol
        if protocol == 'any':
            protocol = None

Thus, this bug report is related to neutronclient side.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/259345

[Akihiro Motoki (amotoki)]

My big question is why we deal with 'protocol' in a special way.
In the security group API, all attributes with a value None means "don't care" i.e., "any".
Why do we need to support "any" only for "protocol"?
I am afraid we are introducing another inconsistency if we add 'any' protocol in SG rule CLI option.

Does anyone answer this question?

FWaaS CLI does it, but it does not convince me.

[li,chen (chen-li)]

@Akihiro Motoki

I do not have a very strong and clean answer to your question.
What I have is:
    1. I use 'any' to indicate all, not None. I found this bug, so, I'm not alone. Just fit into users' behavior.
    2. This doesn't hurt any other things.

And, in #3, for your own words : CLI option is different. I think it should be more descriptive, so it sounds reasonable to display "any" in the help message.

Actually, I think neutron side need a little change too, because whatever we did in neutron-client, when user give a wrong protocol, the error message returned from neutron-server would still say it support "None, xxxxx", it is confusing.

[OpenStack Infra (hudson-openstack)]

Change abandoned by li,chen (<email address hidden>) on branch: master
Review: https://review.openstack.org/259345

[Armando Migliaccio (armando-migliaccio)]

This bug is > 180 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Launchpad Janitor (janitor)]

[Expired for python-neutronclient because there has been no activity for 60 days.]

[Shachar Snapiri (snapiri)]

I believe this bug is still relevant.
Currently there is no way to create a security rule that is agnostic to the protocol via the CLI, though it is possible via the UI or programatically.
This is an inconsistent behavior and prevents functionality from CLI users.
To me it seems that there is no real technical issue with adding it, but it is rather a matter of getting to agree on the right syntax.
I am not sure why this was abandoned (could not find any real reason here), so I would like to try and revive it.

[Akihiro Motoki (amotoki)]

Shachar,
you can create a security group rule that is agnostic to the protocol if you don't specify --protocol option.

ubuntu@sheep6:~ [OS_CLOUD:devstack][15:51:42]$ neutron security-group-rule-create --ethertype IPv4 test-sg
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Created a new security_group_rule:
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| created_at | 2017-11-01T15:52:08Z |
| description | |
| direction | ingress |
| ethertype | IPv4 |
| id | 6c71f44d-132b-400f-9599-7ec597f7e915 |
| port_range_max | |
| port_range_min | |
| project_id | df94225fa87446e2858521a1236752b4 |
| protocol | |
| remote_group_id | |
| remote_ip_prefix | |
| revision_number | 0 |
| security_group_id | bc04ceff-28d5-4e12-b753-39047c5e7732 |
| tenant_id | df94225fa87446e2858521a1236752b4 |
| updated_at | 2017-11-01T15:52:08Z |
+-------------------+--------------------------------------+

[Shachar Snapiri (snapiri)]

In that case I must have missed something.
I recall from some time ago that the protocol had a default of TCP.
I have retested and (of course) you are right.

[Trent Lloyd (lathiat)]

In case someone discovers this bug trying to match any protocol with the 'openstack' client (openstackclient), it was not possible to create such a rule but it was recently fixed in Bug #1712242 - you can now specify 'any'

https://bugs.launchpad.net/python-openstackclient/+bug/1712242
https://review.openstack.org/#/c/512113/

Fix was committed Oct 2017, is not in the Pike release so presumably will be in Queens.

Given that the 'neutron' client is deprecated and planned for removal, and there is a function (you can use None, just not 'any') I suspect this bug should probably be closed as WONTFIX since people shouldn't be using the neutron client for new applications, and old applications would want to use the "None" parameter for backwards compatibility.

The 'openstackclient' fix uses any and thus is in line with the original request of this bug (even though it was for neutronclient)