In some cases when firewall is created and then deleted in short
period of time, there could be a race condition of firewall status
changes. Agent may change firewall status from PENDING_DELETE to ACTIVE
because the agent has just set it up on the backend.
Delete request then is not properly served and firewall remains in ERROR
state and can't be deleted at all.
To fix this changing status from PENDING_DELETE is not allowed.
Deleting firewall in ERROR state is allowed.
Change-Id: Iec3cfcb1e03b33dda8e1f10ca51bd9b61fa8030d
Closes-Bug: #1328162
This class is intended for easy and iterative migration from
oslo-incubator RPC implementation to oslo.messaging. It will adapt
oslo.messaging API to old oslo-rpc interfaces.
Migrated all affected classes to the new RpcProxy class.
blueprint oslo-messaging
Change-Id: I1563c13b470b61eebc982ee81efee47732943d48
If firewall rule is attached to firewall policy, it would raise
FirewallRuleInUse excpetion in DB ops, else it is a pure DB delete ops.
So it is useless to handle delete_firewall_rule ops in fwaas plugin.
Closes-Bug: #1322076
Change-Id: I55a000d206f232c79b41230f526007f684db8f4f
By default, iptables apply is deferred in L3 agent. For
external gateways, iptables is applied immediately (to
enable NAT for floating IP). Similarly, when firewall
is created/updated/deleted, iptable rules are applies
immediately.
Change-Id: I4f652a030ae23a71a2e20af2e8ef0ad5b882b80e
Closes-Bug: #1320775
Second firewall creation returns 500, but it is an expected behavior
of firewall reference implementation and an internal server error
should not be returned.
Change-Id: I9f537b238007d35172e2504591d9d3568ba3a41a
Closes-Bug: #1301105
Previously admin tenant cannot create a firewall if other tenant
already created a firewall. We need to count firewalls only in
a target tenant.
Change-Id: I3e6d151d00d4a487bdd858e94929fab8960511a2
Closes-Bug: #1258438
The workflow of creating a firewall when a router without any i/f is present in that tenant
causes a KeyError on the FWAgent. The issue occurs as such routers are present in the list of
routers returned by get_routers() but are not populated in the router_info dict. Adding a check
before accessing the dict to prevent the exception. When an i/f is added to such routers -
_router_added processing in the l3agent will populate the router_info dict and the FWAgent
also picks this up in that context.
Change-Id: I5ea22e88a46e62372a0462e9cb958a08dd9f4c7d
Closes-Bug: #1289643
o neutron/services/firewall/drivers/linux/iptables_fwaas.py:FWAAS_CHAIN
= 'fwaas'
This variable was added in the following commit.
commit 7e48716086
Author: Rajesh Mohan <rajesh.mlists@gmail.com>
Date: Fri Jun 21 17:55:08 2013 -0700
Firewall as a Service (FWaaS) Iptables Driver
But there is no evidence that was used.
Change-Id: I5633e74e2441b71e3dddaa0c2f6a5804778e21e1
Currently firewall remains in status "ACTIVE" after admin state
is changed to DOWN.
This fix sets firewall status to "DOWN" if admin state is updated
from "UP" to "DOWN". "DOWN" status is used by other network resources
so use "DOWN" to keep consistent.
Change-Id: If316b114c4df78368b43c2a15a820bb1177b3a54
Closes-Bug: 1279213
Some config options(interface_driver, use_namespaces) are defined
multiple times in ad-hoc way. It causes DuplicateOptError exception
when using those module at the same time. Right now the exception is
avoided in ad-hoc way by each executable. Those duplicated
definitions should be consolidated and treated in uniformed way.
This is the blocker for blueprint: l3-agent-consolidation
neutron.services.loadbalancer.drivers.haproxy.agent periodic_interval
conflicts with neutron.service one. Since there is no way to fix it
without changing existing behavior/default value, it is untouched for now.
Closes-bug: #1279769
Change-Id: Ifed79b7ee0033644854499416f8a2b22a20416fe
This patch fixes the issue of writing the wrong firewall rule where an IP6
rule is written to IP4.
Change-Id: Ie7c75c71c9dcfbd9feabaffe4416ede80ff350d8
Closes-Bug:#1263877
Remove the FWaaS Noop driver as the default and raise an exception
when the fwaas_driver.ini file has an enabled flag without any
associated driver. This communicates a misconfiguration clearly.
The Noop driver is moved to unit tests where it is used.
Also some cleanups in related area.
Closes-Bug: #1250841
Change-Id: Ib6345923df05994ceffc0b1cbf265b53c23e97f1
Refactor _spawn/destroy_metadata_proxy so that it can be called
with only the namespace and the router_id.
Change-Id: Id1c33b22c7c3bd35c54a7c9ad419831bfed8746b
Closes-Bug: #1252856
__metaclass__ cannot be used in python3.
six be used in general for python 3 compatibility.
Change-Id: Ib0d71b9676dc01390679396443575c05975d3b58
Closes-Bug: #1236648
fixes Bug #1240812
When iterating through the rule list, we should not change the rule itself.
So that we can use the rule data for the second router.
Change-Id: I613438507949007bec41416e7f8530693e4d5129
Firewall will in PENDING_CREATE state if there is no underlying router in the
tenant. When the router and an associated i/f is created then with a sequence
of msgs it is set to ACTIVE state by the plugin. If a delete is triggered when
in PENDING_CREATE state in such a situation, the msg was ignored - fixing this to
account for the fact that a delete makes sense in this situation so the agent
sends the appropriate msg back to the plugin so it can delete it.
Change-Id: Id1db0a8413fd815b518fe4dc57fc6277c09e7f00
Closes-Bug: #1223478
The reference implementation of the FWaaS iptables
agent/driver supports only one firewall per tenant
in Havana release. However, the FWaaS plugin will
let you create more than one firewall. This is
being fixed in this patch to not allow creating
the second firewall if a firewall already exists
for the tenant.
Change-Id: I8f1cad9791723ba919b5774a63982c204686ddfe
Closes-Bug: #1228442
Partial-Bug: #1217100
Using tools/check_i18n.py to scan source directory, and fix most of
the errors.
- Message internationalization
- First letter must be capital
- Using comma instead of percent in LOG.xxx
Note: all extension's description are not touched in this patch,
can be fixed after discussing.
Note: all nicira/check_nvp_config.py print messages are not fixed.
Change-Id: I79ef06fd42f6780beb5019c592662536c2a51864
This patch enables vArmour's routing and firewall services to be deployed in
openstack environment.
- as gateway for internal networks
- support SNAT and DNAT (floating IP)
- FWaaS services
Implements: blueprint varmour-fwaas-driver
Change-Id: I6ddfa3137ed7e2a3fcf16a764d1340a8eae9359a
blueprint quantum-fwaas-iptables-driver
This is IPTables Driver for "Firewall As A
Service" feature.
This implements
- Fwaas rules are mapped to IPTables
- The rules are installed in the network
namespace of quantum-routers
Change-Id: I157182f2c86fbcf8c141b9ad3cfc71168153ebf8
blueprint: quantum-fwaas-agent
This is the first iteration of the FWaaS Agent with some basic
functionality to enable integration of Plugin - Agent - Driver.
An inheritance approach is taken with the L3 Agent to enable the
agent side messaging.
Unit tests, included, coverage being increased
Change-Id: Ib0970fdc4ad1ac53df66fba172a5a7f7d7ee3f1b
Implements: blueprint quantum-fwaas
blueprint: quantum-fwaas-plugin
This is the first iteration of the FWaaS implementation and
is geared towards implementing the model that will be
required to at least address the reference implementation.
This iteration will not include implementation of the following
features:
* grouping or dynamic objects
* application/service objects
Change-Id: I57a62d6e9d3f1e6c4dd44cd5c745710a3d9e488e
Eugene Nikanorov