Fixed the check for network namespace path.

[asridharan]

The expectation on older kernels (< 3.19) was to have the network
namespace always be a directory. This is not true if the network
namespace is bind mounted to a file, and will make the plugin fail
erroneously in such cases.

I have tried this with Mesos on a CentOS 7 cluster, running 3.10 kernel and it works fine. Moreover, have also tried it on Ubuntu 14.04 which has 3.13 kernel and works fine on that as well.

This should fix #288

[jieyu]

I suggest we completely remove this check. As @asridharan pointed out, namespace handles can be bind mounted. Container runtime might choose to do the bind mount to keep the namespace open. This is a very common practice.

[dcbw]

Seems OK to me... I think the main reason for the "ns" path check was to capture stuff like /proc/18768/task/18798/ns/net.

[tomdee]

Yep, no objection from me either. @steveej any thoughts?

[asridharan]

So the consensus is to remove the check completely under the PROCFS_MAGIC block?
So I guess the point of the switch stat.Type check would be to only check that the file system type returned is PROCFS or NSFS.

[asridharan]

@tomdee @steveej thoughts on the new changes?

We were blocked on this for a DC/OS 1.8 release and would like to get these changes in, if the PR looks good.

Thanks a lot !!

[rosenhouse]

LGTM, perhaps pending a change to the commit-message style so that it follows the contribution guidelines?

[asridharan]

@rosenhouse updated the commit message to follow the contribution guidelines. For the subsystem field I used packages. If there is a pre-defined list of sub-system that we can pick from and this needs to be changed please advise.

[dcbw]

@asridharan if you change the prefix to "pkg/ns" then I'll merge it. Thanks!

[dcbw]

@asridharan I don't think there's a predefined list, but a quick "git log pkg/ns" or for whatever module will show what previous commits have used.

[asridharan]

Ah !! @dcbw thanks!! Just updated the commit message.

[dcbw]

@steveej this seems reasonable to me for now; if we want to catch random /proc paths passed in I guess we should figure out what to do there and take bind-mounted paths into account too. Merging for now...