This preserves the existing behaviour of showing count=0 as a plural
rather than empty. However, I rather suspect we cannot actually
encounter that case in the current code.
In the "no count found" case we now *set* the base.LabelMinor to empty
instead of leaving it alone. This is ok since it is empty to begin with.
Use string for delay and packet loss parameter, code refactoring,
improved error messages, fix typos, add empty status representation,
fix namesapce ID representation.
To avoid to run `tc` every tic to get the qdisc status, we cache it.
The cache is updated every time a value is changed via the control interface.
NOTE: This will keep track only of the changes by done the plugins interface,
if the qdisc parameters are changed by another applcation or by the user
via terminal, such changes will not be caught.
This patch sends the delay and packet loss values along with
the container metadata. In this way the user has a direct feedback
about the traffic control plugin status.
As it is an initial implementation, it only controls latency of the
outgoing (egress) traffic. There is also a TODO to turn this plugin
into something more serious. Also, at some point we may consider
moving this plugin outside of "example" directory.
We will use this code to execute the code in some process' network
namespace.
I did the vendoring a bit differently, as gvt seems to be a bit dumb
about getting dependencies for test packages (it tried to vendor
ginkgo and gomega, since cni tests are using it).
Also, instead of vendoring golang.org/x/sys as
github.com/containernetworking/cni/vendor/golang.org/x/sys I moved it
to scope's vendor directory.
There were two problems:
- the renderer was looking for reverse names on the destination
- the probe was not annotating source nodes with reverse-resolved names
Fixes#1847
For counting we were using a table keyed on a struct containing Node
pointers. For connections between ordinary nodes this works just
fine. But for connections to/from the Internet node we want to track
individual address/port combinations, which involves an extra
lookup. Since our data structures generally contain values, not
pointers, this produces aliases. As a result n connections from/to a
node to/from a specific Internet IP+port would result in n rows in the
count table, each with a count of 1, instead of one row with a count of
n.
Things wouldn't be so bad if it was actually rendered like that -
annoying, but at least accurate - but...
Each row has an ID which is computed from the node IDs and ports. Not
Node references. The ID must be unique - the frontend will only
render *one* thing per ID. Since the row IDs of our n rows are all the
same, we see one row with a count of 1 instead of n rows with a count of
1.
Furthermore, since the frontend's table row limiting is counting rows,
not unique row IDs, a) fewer rows would be rendered than expected, and
b) the displayed count of the number of extra rows would be too high.
The fix is to replace the Node pointers in the key with Node IDs. This
does require an extra table lookup when we come to produce the rows, but
that is just a fairly cheap map lookup.
Fixes#1495.
