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 involved object is important and only some events include its
name in the message. Change the `Kind` column to `Object` and print
the object in `resource/name` form to allow copy and paste
to `kubectl get`. Also move the source field column to the right
of involved object since it is related.
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.
that requests any device plugin resource. If not, re-issue Allocate
grpc calls. This allows us to handle the edge case that a pod got
assigned to a node even before it populates its extended resource
capacity.
`elbv2.AddTags` doesn't seem to support assigning the same set of
tags to multiple resources at once leading to the following error:
Error adding tags after modifying load balancer targets:
"ValidationError: Only one resource can be tagged at a time"
This can happen when using AWS NLB with multiple listeners pointing
to different node ports.
When k8s creates a NLB it creates a target group per listener along
with installing security group ingress rules allowing the traffic to
reach the k8s nodes.
Unfortunately if those target groups are not tagged, k8s will not
manage them, thinking it is not the owner.
This small changes assigns tags one resource at a time instead of
batching them as before.
Signed-off-by: Brice Figureau <brice@daysofwonder.com>
