quantum-netns-cleanup does not stop metadata proxies

Bug #1115999 reported by Isaku Yamahata
42
This bug affects 7 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Unassigned

Bug Description

The quantum-netns-cleanup does not properly stop metadata proxies when cleaning up.

Tags: l3-ipam-dhcp
affects: devstack → quantum
Revision history for this message
Maru Newby (maru) wrote :

I seem to remember Mark McClain indicating that the behaviour in question was by design. Just as stopping the l3 agent (intentionally or no) doesn't revert iptables entries or the routing table, the proxy should probably continue running to ensure VM connectivity to the metadata service. I'm adding Mark as a bug subscriber to get his feedback.

Revision history for this message
dan wendlandt (danwent) wrote : Re: [Bug 1115999] Re: quantum-ns-metadata-proxy remains after stopping quantum

I recall something similar as well. This likely means that distros (and I
consider devstack a simple distro) should have their own mechanism for
killing these processes if you are really completely shutting things down.

dan

On Tue, Feb 5, 2013 at 1:09 PM, Maru Newby <email address hidden> wrote:

> I seem to remember Mark McClain indicating that the behaviour in
> question was by design. Just as stopping the l3 agent (intentionally or
> no) doesn't revert iptables entries or the routing table, the proxy
> should probably continue running to ensure VM connectivity to the
> metadata service. I'm adding Mark as a bug subscriber to get his
> feedback.
>
> --
> You received this bug notification because you are a member of Netstack
> Core Developers, which is subscribed to quantum.
> https://bugs.launchpad.net/bugs/1115999
>
> Title:
> quantum-ns-metadata-proxy remains after stopping quantum
>
> Status in OpenStack Quantum (virtual network service):
> New
>
> Bug description:
> quantum l3 agents spawns quantum-ns-meadata-proxy.
> They remains after stopping quantum.
> So they should be killed when stopping quantum.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/quantum/+bug/1115999/+subscriptions
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Revision history for this message
Mark McClain (markmcclain) wrote : Re: quantum-ns-metadata-proxy remains after stopping quantum

This is by design, so that both the L3 and metadata proxy stay at a steady state when the agent is stopped for upgrades, minor configuration changes, or other needs.

f you want to fully clean-up the namespaces, you need to run quantum-netns-cleanup and this utility does not properly stop the proxies. Would you mind if I changed the object of this bug to update quantum-netns-cleanup to properly cleanup the proxies?

Revision history for this message
Isaku Yamahata (yamahata) wrote :

Mark, I got it. Will do

tags: added: l3-ipam-dhcp
summary: - quantum-ns-metadata-proxy remains after stopping quantum
+ quantum-netns-cleanup does not stop metadata proxies
description: updated
Changed in quantum:
status: New → Confirmed
assignee: nobody → Mark McClain (markmcclain)
importance: Undecided → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (master)

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

Changed in quantum:
assignee: Mark McClain (markmcclain) → Isaku Yamahata (yamahata)
status: Confirmed → In Progress
Revision history for this message
Akihiro Motoki (amotoki) wrote :

I think this bug is important to make netns-cleanup as expected.
We cannot remove network namespaces without stopping running metadata proxies.
It means quantum-netns-cleanup as cron job cannot remove orphaned network namesapces.

From the point of view of usability, I think it is worth targeted to G-rc1 (at least it is worth on the list we watch)

Changed in quantum:
milestone: none → grizzly-rc1
dan wendlandt (danwent)
Changed in quantum:
importance: High → Medium
Changed in quantum:
milestone: grizzly-rc1 → havana-1
Revision history for this message
Mark McClain (markmcclain) wrote :

This review was abondoned. Need to triage again after H1 cut.

Changed in quantum:
milestone: havana-1 → none
Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

I would like to take care of this bug to get it fixed for icehouse.

Changed in neutron:
status: In Progress → New
Revision history for this message
Marios Andreou (marios-b) wrote :

raising my hand to volunteer to sort this out. i expect it will be a whole world of pain to rebase that review though (quantum!). Will assign to myself once I've had a chance to actually pull the code down and poke at it and see if i can actually do it whilst maintaining at least a bit of sanity to bring to summit.

Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

Marios, please go ahead with the fix

Changed in neutron:
assignee: Isaku Yamahata (yamahata) → nobody
assignee: nobody → Marios Andreou (marios-b)
status: New → Confirmed
Revision history for this message
Marios Andreou (marios-b) wrote :

sure thing, will try and carve out some time last week. I *did* poke at it briefly - basically I think the only sane way forward is to figure out which parts of the related review are still relevant and then manually port them over. As I said will pick it up again next week.
thanks

Revision history for this message
Miguel Lavalle (minsel) wrote :

Haven't seen activity in this bug for more that a year. Marking incomplete

Changed in neutron:
status: Confirmed → Incomplete
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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.

Changed in neutron:
assignee: Marios Andreou (marios-b) → 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
Revision history for this message
Daniel Alvarez (dalvarezs) wrote :

This bug is closed by this patch [0]. When running netns-cleanup, it will search for all processes that live in the namespace and are listening on any socket (tcp(6), udp(6), unix socket) and kill them. In the case of metadata-proxy, as it listens on TCP 9697, it will be also killed.

[0] https://review.openstack.org/#/c/402140/

Changed in neutron:
status: Expired → Fix Released
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.