[Devel] namespace-related issues in pykdump and openVZ-specific patches

[Moore, Martin (Linux ERT)]

Hello Vasily,

I have added you as a developer to the project.  Welcome aboard.  There are no formal rules as far as commits beyond "please try not to break anything". 😊  

Regards,
Martin

Explore the HPE digital support experience: https://support.hpe.com

Martin Moore
Linux Engineering Resolution Team
HPE Pointnext Services
Hewlett Packard Enterprise

Martin.Moore at hpe.com 
8AM-5PM EST (UTC-5) Monday-Friday
Manager: Becky McBride (becky.mcbride at hpe.com)

-----Original Message-----
From: Vasily Averin <vvs at virtuozzo.com> 
Sent: Wednesday, November 10, 2021 12:53 AM
To: Moore, Martin (Linux ERT) <martin.moore at hpe.com>; OpenVZ devel <devel at openvz.org>
Subject: Re: namespace-related issues in pykdump and openVZ-specific patches

Dear Martin,
I've registered on Sourceforge as vaverin, please add me into pykdump developer's list.
I'm going to commit trivial fixes into dev branch, discuss Tasks.py changes on wiki first, and perhaps create new branch for OpenVz specific changes (though I hope it can be merged into dev branch too).
Please let me know if you have any rules/highlights/requirements about commits into the project.

Thank you,
	Vasily Averin


On 04.11.2021 17:23, Moore, Martin (Linux ERT) wrote:
> Hello Vasily,
> 
> Thanks for your interest in pykdump!  First let me note that Alex 
> Sidorenko retired from HPE several months ago, so I've removed his 
> (defunct) hpe.com email address.  Alex is still around and doing some 
> open source programming; I'm in touch with him, which is a good thing 
> since he was the creator and principal developer of pykdump and knows 
> it much more intensively than I do. :)
> 
> We don't have a mailing list or a formal method of submitting patches, as the level of activity on the project has never seemed to require one.  There is a discussion board (https://sourceforge.net/p/pykdump/discussion/ ) that isn't very active, but it does get read.  We only have a small number of developers, who mostly work out of the dev branch and just commit patches there as needed.  Generally useful commits get merged into the master.  We’re always open to new developers, and I would be happy to add you and/or colleagues if you'll provide the Sourceforge user IDs.
> 
> For trivial fixes such as the one you mentioned to LinuxDump/Tasks.py, it would be fine to use dev for this purpose.  However, if any changes require significant modifications to the pykdump framework or API, then it would probably be best to create a new branch.  Or if your end goal is to have a separate openVZ-specific version of pykdump, you could fork a new project.  Or you can do some combination of these options as appropriate.
> 
> Please let me know if you have any other questions or would like to be added as a developer to the project.
> 
> Regards,
> Martin
> 
> Explore the HPE digital support experience: https://support.hpe.com
> 
> Martin Moore
> Linux Engineering Resolution Team
> HPE Pointnext Services
> Hewlett Packard Enterprise
> 
> Martin.Moore at hpe.com
> 8AM-5PM EDT (UTC-4) Monday-Friday
> Manager: Becky McBride (becky.mcbride at hpe.com)
> 
> -----Original Message-----
> From: Vasily Averin <vvs at virtuozzo.com>
> Sent: Wednesday, November 3, 2021 3:19 PM
> To: Alex Sidorenko <alexandre.sidorenko at hpe.com>; Moore, Martin (Linux 
> ERT) <martin.moore at hpe.com>; OpenVZ devel <devel at openvz.org>
> Subject: namespace-related issues in pykdump and openVZ-specific 
> patches
> 
> Alex, Martin,
> 
> I use your nice pykdump tools for troubleshooting of OpenVZ kernels.
> 
> Our kernels allow to run hundreds of well-isolated LXC-like containers, and uses a lot of various namespaces.
> 
> Pykdump interface have --usens option, and in general it works well.
> Unfortunately it does not help in some cases, for example
> - xportshow --arp for task inside container still shows routes related 
> to init_netns
> - nfsshow does not show container-related information too.
>     get_nfs_mounts() get mounts from getMount() that works with host mounts only.
> I've ignored some minor issues, fixed some simple cases, but still hаve troubles with complex issues and would like discuss how to fix them properly.
> 
> Additionaly we would like to adapt pykdump for our kenrel.
> Our kernel includes ~1000 our own patches in various subsystems.
> Some of them "virtualizes" some interfaces, to allow uses and change them safely from inside containers.
> For example we have replaces global pid_max variable by additional per-pidnamespace parameter, as result LinuxDump/Tasks.py fails on readSymbol("pid_max") Fix is trivial and we would like to push it pykdump.
> 
> Also we would like to add some openVZ specific commands.
> Sometime ago I've prepared vz.c crash extension 
> https://github.com/crash-utility/crash-extensions/blob/master/vz.c
> Recently I've implemented this functionality in pykdump-python scripts.
> Is there any chances to include them into pykdump core?
> 
> Could you please clarify, what is right way to discuss and submit any patches to pkdump?
> Where is the proper place to discuss such kind of questions?
> Do you have perhaps some bug tracker or pykdump-specific mailing list?
> If you wish I can create such mailing list on openvz.
> 
> Thank you,
>     Vasily Averin
>