rackspace / gophercloud

A Go SDK for OpenStack. IN FEATURE FREEZE. See Issue #592
http://gophercloud.io
Other
456 stars 185 forks source link

Openstack: FWaaS rules do not support "any" protocol #605

Open carlpett opened 8 years ago

carlpett commented 8 years ago

Setting protocol "any" when creating a new rule gives an error

Expected HTTP response code [201 202] when accessing [POST https://OPENSTACK-PROVIDER:9696/v2.0/fw/firewall_rules], but got 400 instead {"NeutronError": {"message": "Firewall Rule protocol any is not supported. Only protocol values [None, 'tcp', 'udp', 'icmp'] and their integer representation (0 to 255) are supported.", "type": "FirewallRuleInvalidProtocol", "detail": ""}}

Setting protocol = "" gives A protocol is required (tcp, udp, icmp or any), and protocol = "0" (since the error message indicated that numerals would be accepted) gives Invalid input for protocol. Reason: '0' is not in [None, 'tcp', 'udp', 'icmp'].

I made a quick attempt at a fix, but it is not very pretty: https://gist.github.com/carlpett/cfef6867d2f5445774fb6a9ca6728efa. Also, it does not manage the read part, since that just passes the result into the pager.

Is there some better way to do the any to nil mapping, which Openstack seems to want?

jtopjian commented 8 years ago

@carlpett I think this is actually an upstream OpenStack FWaaS issue. The error message you're seeing is from Neutron and not Gophercloud.

According to the FWaaS code, "any" is really not supported:

https://github.com/openstack/neutron-fwaas/blob/905c798db15e0a02bffe2014013be99f9943f56f/neutron_fwaas/extensions/firewall.py#L170-L172

Edit: Ah - None. So having a nil/None/empty key of protocol allows for all protocols? In that case, maybe something like this will work in Gophercloud:

if opts.Protocol != "" {
    r["protocol"] = opts.Protocol
} else {
    r["protocol"] = nil
}

Which is almost exactly what you have in your gist :smile:

carlpett commented 8 years ago

@jtopjian Yep :smile: I guess the question is if it is preferrable for the user to explicitly say "any", or if it should be the default. I guess having it as the default (which would be the result of your snippet, right?) would be easier, even if it might be a bit unexpected. Can be solved by documentation, of course.