RequiredIPVSKernelModulesAvailable warning confuses users suggesting
that the IPVS proxier will not be used, which is not always the case.
Made the warning message less confusing:
[WARNING RequiredIPVSKernelModulesAvailable]:
The IPVS proxier may not be used because the following required kernel
modules are not loaded: [ip_vs_rr ip_vs_wrr ip_vs_sh]
or no builtin kernel ipvs support was found: map[ip_vs_wrr:{}
ip_vs_sh:{} nf_conntrack_ipv4:{} ip_vs:{} ip_vs_rr:{}].
However, these modules may be loaded automatically by kube-proxy for you
if they are available on your system.
To verify IPVS support:
Run "lsmod | grep 'ip_vs\|nf_conntrack'" and verify each of the above
modules are listed.
If they are not listed, you can use the following methods to load them:
1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe
ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install
the missing module support for your kernel.
Fixes: kubernetes/kubeadm#975
Found using script:
https://gist.github.com/dims/384dea60754042f61d79233603034038
Just run using:
`find . -name .import-restrictions | xargs python ~/junk/sanitize-import-boss.py`
The removed entries are either packages that got moved/renamed/deleted
but are still not cleaned up from .import-restrictions files.
Change-Id: I92c400f74e6f012cc75539311ed4de280e25e918
The messages for container lifecycle events are subtly inconsistent
and should be unified.
First, the field format for containers is hard to parse for a human,
so include the container name directly in the message for create
and start, and for kill remove the container runtime prefix.
Second, the pulling image event has inconsistent capitalization, fix
that to be sentence without punctuation.
Third, the kill container event was unnecessarily wordy and inconsistent
with the create and start events. Make the following changes:
* Use 'Stopping' instead of 'Killing' since kill is usually reserved for
when we decide to hard stop a container
* Send the event before we dispatch the prestop hook, since this is an
"in-progress" style event vs a "already completed" type event
* Remove the 'cri-o://' / 'docker://' prefix by printing the container
name instead of id (we already do that replacement at the lower level
to prevent high cardinality events)
* Use 'message' instead of 'reason' as the argument name since this is a
string for humans field, not a string for machines field
* Remove the hash values on the container spec changed event because no
human will ever be able to do anything with the hash value
* Use 'Stopping container %s(, explanation)?' form without periods to
follow event conventions
The end result is a more pleasant message for humans:
```
35m Normal Created Pod Created container
35m Normal Started Pod Started container
10m Normal Killing Pod Killing container cri-o://installer:Need to kill Pod
10m Normal Pulling Pod pulling image "registry.svc.ci.openshift.org/openshift/origin-v4.0-2019-02-10-172026@sha256:3da5303d4384d24691721c1cf2333584ba60e8f82c9e782f593623ce8f83ddc5"
```
becomes
```
35m Normal Created Pod Created container installer
35m Normal Started Pod Started container installer
10m Normal Killing Pod Stopping container installer
10m Normal Pulling Pod Pulling image "registry.svc.ci.openshift.org/openshift/origin-v4.0-2019-02-10-172026@sha256:3da5303d4384d24691721c1cf2333584ba60e8f82c9e782f593623ce8f83ddc5"
```
The rules for address parsing are:
* Explicitly specified addresses must bind successfully
* `localhost` is pinned to `127.0.0.1` and `::1` and at least one of those must bind successfully
This change also makes output of the command consistent
between runs with the same arguments.
Previously the command was using the range via map of addresses
which sometimes was producing different output because the order
of values is not guaranteed in Go.
Ed Bartosh