Since d60874aca8 `connectionTracker` can
fallback when the `EbpfTracker` died. Hence we only have to stop the
`tracer` in `stop()`.
This commit is also a fixup for d60874aca8
where we do a gentle fallback but never actually stop the tracer to stop
polling.
Structs like StringLatestMap now use ps.Map directly, which saves
a memory allocation for LatestEntry.Value to point to.
The values in the ps.Map are now pointers, which saves a memory
allocation indirecting a value type to an interface{}
This reverts commit 76ddc75fb8, reversing
changes made to 3ade2933eb.
We are rolling this back for now because it's causing a bug where sub-topologies
would have ~3000 repeated cases of the k8s filters, causing performance issues clientside.
* The Stderr pipe should be read before waiting
* The Stderr pipe should not be used with Run/Output. See https://golang.org/pkg/os/exec/#Cmd.StderrPipe:
Wait will close the pipe after seeing the command exit, so most callers need
not close the pipe themselves; however, an implication is that it is incorrect
to call Wait before all reads from the pipe have completed. For the same
reason, it is incorrect to use Run when using StderrPipe.
To facilitate this, we replace the existing functionality of updateFilters which
sets k8s topologies to have the filters [namespace, managed], to instead append the namespace filter
to any existing. This lets it apply to both k8s and container topologies without overwriting existing
container filters. We instead set the managed filter in the static definition.
This however has the side effect that the ordering of the namespace filter and the managed filter
in k8s topologies has been reversed, so it reads:
Show Unmanaged | Hide Unmanaged
foo | bar | default | baz | All Namespaces
instead of:
foo | bar | default | baz | All Namespaces
Show Unmanaged | Hide Unmanaged
`launch` first does a `scope --dry-run` to parse and validate Scope
cmdline arguments before starting the main Scope container and
processes. Use the same Docker args for the dry run to make sure the
container has the same privileges and mount points. Otherwise valid
`$WEAVESCOPE_DOCKER_ARGS` might fail here.
