The host CPU metric was reported as a percentage of all available CPUs,
but the limit was set to n_cpus * 100%. So on a 4-core machine the
graphs and metrics-on-canvas would never show more than 1/4th usage. Now
the limit is set to 100%.
Fixes#1664.
The container CPU metric was reported in units of 100% = 1 CPU. So the
the ratio was correct, but since we don't show limits in most places it
is hard to interpret that figure. It also makes sorting by CPU usage
highly misleading. So now we normalise everything to 100%. That too can
be misleading, depending on what you are looking for, but it's generally
less surprising.
* if a node table has `controls` they will be rendered in a row
* controls need the to be of the same structure as node-level controls
* control errors are not shown
- Increase line height so that it doesn't fall over the side of the
container (which is overflow: hidden).
- Compensate for line-height increase w/ small label position tweak.
This fixes the case where the provided paths do not contain any shell scripts,
ie. xargs is passed no values.
In this case by default, xargs invokes the command once with no args.
This causes shellcheck to print usage and exit failure.
The GNU-specific --no-run-if-empty changes the behaviour so that in this case,
shellcheck is simply never run.
This allows us to use this script as a general lint even in contexts where
no shell scripts are present, or none of the files passed are shell scripts.
* Squashed 'tools/' changes from e9e7e6b..db5efc0
db5efc0 Merge pull request #28 from weaveworks/mike/add-image-tag
5312c40 Import image-tag script into build tools so it can be shared
7e850f8 Fix logs path
dda9785 Update deploy api
f2f4e5b Fix the wcloud client
3925eb6 Merge pull request #27 from weaveworks/wcloud-events
77355b9 Lint
d9a1c6c Add wcloud events, update flags and error nicely when there is no config
git-subtree-dir: tools
git-subtree-split: db5efc0537
* Remove ./image-tag and use ./tools/image-tag instead
image-tag is now shared code from the build-tools repo
We fell victim to variable shadowing here. Each store would be fed the
original list of report keys, instead of only the ones that weren't
found in the previous store. So if a single report was missing from the
in-process cache, we would then fetch all reports from memcache. And if
that in turn was missing a single report we would fetch all reports from
S3.
We chain report stores for a reason - to reduce latency and, in case of
the in-process cache, eliminate decoding costs. So this bug has a huge
impact on query service performance.
To make matters worse, we return *all* the reports - now possibly in
triplicate. Fortunately, the SmartMerger filters these out, so at least
we were not incurring extra merge costs.
