cnitool: fix default CNI directory on Windows and add extra checks.

[aznashwan]

No description provided.

[aznashwan]

Note that the only new validation logic which may introduce extra constraints is this new filepath.IsAbs() check, but I can't think of a usecase where one might want to use a relative path instead of an absolute path.

I'm also open to any better suggestions for the Windows default path than this default from containerd.

[coveralls]

Coverage: 72.359%. Remained the same when pulling 289c64b on aznashwan:fix-default-windows-confdir into 6a43fb5 on containernetworking:main.

[aznashwan]

Note that the only new validation logic which may introduce extra constraints is this new filepath.IsAbs() check

FWIW I have switched to using filepath.Abs() to bring it in line with the rest of the code.

I've also compared the pre and post-patch behavior on Linux:

### Pre-patch:
# Relative paths work:
$ NETCONFPATH=../../../../etc/cni/net.d/ ./cnitool check nonexistent-net /var/run/netns/testing 
no net configuration with name "nonexistent-net" in ../../../../etc/cni/net.d/  # correct 

# Setting a nonexistent directory will only claim there are no net configurations:
$ NETCONFPATH=/nonexistent/path ./cnitool check nonexistent-net /var/run/netns/testing 
no net configurations found in /nonexistent/path

# Setting a nonexistent relative directory will also only claim there are no net configurations:
$ NETCONFPATH=./nonexistent/relative/path ./cnitool check nonexistent-net /var/run/netns/testing 
no net configurations found in ./nonexistent/relative/path

### Post-patch:
# Relative paths still work:
$ NETCONFPATH=../../../../etc/cni/net.d/ ./cnitool check nonexistent-net /var/run/netns/testing 
no net configuration with name "nonexistent-net" in /etc/cni/net.d  # correct

# Setting a nonexistent directory will error out with a clear message:
$ NETCONFPATH=/nonexistent/path ./cnitool check nonexistent-net /var/run/netns/testing 
the provided CNI config path ($NETCONFPATH) does not exist: "/nonexistent/path"

# Setting a nonexistent relative directory will also error out with a clear message:
$ NETCONFPATH=./nonexistent/relative/path ./cnitool check nonexistent-net /var/run/netns/testing 
the provided CNI config path ($NETCONFPATH) does not exist: "/home/nashu/cni/cnitool/nonexistent/relative/path"

[dcbw]

@aznashwan this seems containerd specific, but CNI is used by more than just containerd. If each CRI implementation has its own default directory, should this be a list of default dirs that get tried in sequence?

[aznashwan]

Sorry for the huge delay, I must've somehow missed this notification when it happened.

seems containerd specific

Correct.

CNI is used by more than just containerd

Correct, but generally not really Windows (at least when I was involved in CNI porting efforts on Windows a whole year ago).

Back then, the vast majority of k8s/docker setups on Windows directly installed containerd from their build scripts in the main containerd/containerd repo, so it seemed like the most reasonable choice...

I'm not sure whether there is a "standardised way" to install k8s on Windows nowadays, but I'm willing to bet it uses containerd with this default.

Plus at the end of the day this path is configurable via an env var, so the C:\Program Files\containerd\cni\conf default isn't preventing anyone from using cnitool, and it's certainly a hell of a lot saner of a default on Windows than /etc/cni/net.d 🤣

[MikeZappa87]

@aznashwan is this still required?

[aznashwan]

@MikeZappa87

is this still required?

While I have't worked with Windows CNIs in over 1 year or so, this patch still looks relevant for anyone wanting to run cnitool on Windows (not sure how relevant that is nowadays however).

I've just rebased the PR FWIW.