[openstack-dev] [neutron] proper cleanup of l3 resources (neutron-netns-cleanup)

Bhatia, Manjeet S manjeet.s.bhatia at intel.com
Tue Oct 11 18:28:37 UTC 2016


Hi,

Approach I am following is not cleaning blindly, there is utility in cleanup which I’ll use
To get eligible namespace candidates for cleanup (need to deep dive this logic how effective is that)
Then will extract id from namespace either using namespace manager or l3 agent code,
And call on l3 agent to cleanup respective namespaces.

and to check cleanup, I am creating a router and setting just a gateway which create namespace,
don’t add any interface, I see it cleans up qrouter-namespace but and I can still see router when I do router-list, which shouldn’t be there, people having knowledge on this pls correct me if I am wrong ?

Thanks and Regards !
Manjeet Singh Bhatia

From: Sergey Belous [mailto:sbelous at mirantis.com]
Sent: Tuesday, October 11, 2016 3:54 AM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] proper cleanup of l3 resources (neutron-netns-cleanup)

Hi, Miguel.

As I can see, Manjeet Singh Bhatia already proposed the change on review [1]—this patch adds the invoking a cleanup provided by l3-agent.
Actually, I like the option 2. And I'm going to implement it and compare to Manjeet's solution.
But can anybody suggest me, how can I manually reproduce the situation where netns-clean is needed to run for cleanup l3 namespaces? In which state should be these namespaces?

[1] https://review.openstack.org/#/c/383936/

On 7 Oct 2016, at 15:38, Miguel Angel Ajo Pelayo <majopela at redhat.com<mailto:majopela at redhat.com>> wrote:

Hi Sergey!,

This was my point of view on a possible solution:

https://bugs.launchpad.net/neutron/+bug/1403455/comments/12

"""
After much thinking (and quite little doing) I believe the option "2"
I proposed is a rather reasonable one:

2) Before cleaning a namespace blindly in the end, identify any
network service in the namespace (via netstat), kill those processes,
so they aren't orphaned, and then, kill the namespace.

Any process should be safely killed that way, and if it's not, we can
complicate our lifes and code with "1":
1) Use stevedore HookManager to let out-of-tree repos register netns
prefixes declaration, and netns cleaners,
   so every piece of code (in-tree or out-of-tree) declare which
netns prefixes they use, and provide a netns cleanup
   hook to be called.

"""

Let me know what you think

On Fri, Oct 7, 2016 at 2:15 PM, Sergey Belous <sbelous at mirantis.com<mailto:sbelous at mirantis.com>> wrote:

Hello everyone.

I’m very interesting in this one
https://bugs.launchpad.net/neutron/+bug/1403455
Can anybody tell me, what is the current status of this bug? Is anybody
working on it now?
And as I can see, there are some options, that was discussed in comments to
this bug and… did anybody decide which solution is the best?


--
Best Regards,
Sergey Belous


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Sergey Belous

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161011/13399e92/attachment.html>


More information about the OpenStack-dev mailing list