firewall status does not become ACTIVE when a router does not exist

Bug #1223472 reported by Akihiro Motoki
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Expired
Low
Unassigned

Bug Description

I use FWaaS combined with OVS plugin and l3-agent.

When I created a firewall with admin user, the status of the firewall didn't change from PENDING_CREATE to ACTIVE even after waiting for one or two minutes.

On the other hand, when I created a firewall with non-admin user, the status of the created firewall became ACTIVE at most after 30 seconds (probably shorter than this).

What is the difference between admin and non-admin?

The detail command line log is here.
http://paste.openstack.org/show/46493/

Tags: fwaas
Akihiro Motoki (amotoki)
tags: added: fwaas
Changed in neutron:
assignee: nobody → Sridar Kandaswamy (skandasw)
Revision history for this message
Sridar Kandaswamy (skandasw) wrote :

In going thru the logs, i am wondering if there is an active router present in the tenant where the firewall is in PENDING_CREATE (6c1d5d5f6d2644a19c207137d8d8e7ac in this instantiation). If there is no router then the firewall is in PENDING_CREATE and when the router is created will go to ACTIVE state. Just want to confirm if this could be the case here,

Revision history for this message
Sumit Naiksatam (snaiksat) wrote :

Thanks Sridar. I agree, we need to confirm if the admin tenant has a router.

Changed in neutron:
status: New → Incomplete
Revision history for this message
Akihiro Motoki (amotoki) wrote :

Thanks Sridar for your investigation.
I completely forgot to check I have a router already. As Sridar pointed out, I didn't have a router in admin tenant. I just ran stack.sh and create a rule, policy and a firewall after stack.sh finished.

I agree that we should check a router exists when a firewall created.
Does it make sense to change the bug summary to "Need to check a router exists when a firewall is created"?

- At least it is not a good idea to stay PENDING_CREATE when a router does not exist. When a firewall instance is inserted into a router ("router service insertion"), we should check whether a router to which a firewall instance is inserted already exists.
- It is confusing to users that we have a status of PENDING_CREATE forever. When a user see PENDING_CREATE, I believe he/she should think a firewall becomes ACTIVE if he/she waits for a while more and don't think it stays PENDING_CREATE forever.

-----

The following is out of scope of Havana release and can be a discussion topic in Icehouse.

After FWaaS supports a service provider, I don't think a single firewall instance can be inserted into a router and a network at the same time (we may be able to migrate a service provider from one to another of course). If a service provider is specified, the provider implementation should check a resource which firewall is inserted into and if the target resource (router, network or ...) doesn't exist the provider should set the status of the firwall properly.

Revision history for this message
Sumit Naiksatam (snaiksat) wrote :

Hi Akihiro, the PENDING_CREATE behavior if the router is not present as per the current design. This is so that the router or the firewall can be created in any order. As we support more than one firewall per tenant in Icehouse and the insertion semantics becomes more explicit, we will revisit this behavior. I would prefer to document this behavior at this time.

Changed in neutron:
status: Incomplete → Triaged
Akihiro Motoki (amotoki)
summary: - firewall status does not become ACTIVE when firewall is create by admin
- user
+ firewall status does not become ACTIVE when a router does not exist
Revision history for this message
Sridar Kandaswamy (skandasw) wrote :

Thanks Akihiro for the comments. And Thanks Sumit for clarifying. Just to add, from this state, when a Router is available on the tenant, the code handles this by checking for firewalls on that tenant from the plugin and installs the policy. After which it sends a status back to the plugin at which point the firewall status will change to ACTIVE.

This is possibly a valid workflow if we think of the firewall as being pre-provisioned for tenant. But i think this is definitely something up for discussion in Icehouse as both of u have pointed out.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

Sridar, Sumit, thanks for the clarification.
It looks reasonable that a router and a firewall can be created in any order.

It raises new questions to me. Let me clarify the expected behavior of FWaaS in **Havana**.

(1) It seems we assume only one firewall instance per tenant, but actually we can create multiple firewall instances per tenant. Is it better to reject multiple firewall instances per tenant to avoid unnecessary confusion?

(2) When a tenant has multiple routers, is a firewall instance mapped onto both routers?

(3) how a router and a firewall are associated with each other. Assume that we have multiple routers (router1, router2) and multiple firewalls (fw1, fw2) in a tenant. Are both fw1 and fw2 inserted onto both routers? If we assume one firewall instance per tenant, this question is not valid.

Although it may be out of scope of this bug, I believe it needs to be clarified.
I just would like to clarify the limitation of Havana release and the future action items for Icehouse.
It helps us document FWaaS expected behavior and the limitations in the next release.

Revision history for this message
Sumit Naiksatam (snaiksat) wrote :

Akihiro, responses to your questions:

1. We did not limit the number of firewall instances created per tenant since the one firewall instance per tenant was an artifact of the reference implementation.

2. Yes.

3. Yes.

Revision history for this message
Sumit Naiksatam (snaiksat) wrote :

A clarification on (3) after checking with Rajesh - in the current implementation, only the latest policy will be in effect (so if fw2 is applied after fw1, only the rules of fw2 will be in effect).

Revision history for this message
Sumit Naiksatam (snaiksat) wrote :

Akihiro, Per the discussion I have created a new bug:
https://bugs.launchpad.net/neutron/+bug/1228442

and posted a fix. This should hopefully address your concern about not creating more than one firewall for the reference implementation.

Revision history for this message
Cedric Brandily (cbrandily) wrote :

This bug is > 365 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.

Changed in neutron:
assignee: Sridar Kandaswamy (skandasw) → nobody
status: Triaged → Incomplete
Changed in neutron:
importance: Undecided → Low
Changed in neutron:
assignee: nobody → Pramod (pramod-raghavendra-jayathirth)
assignee: Pramod (pramod-raghavendra-jayathirth) → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.