Hi -
> > [...]
> > Please check closer. Nothing appears to have changed about container
> > naming policy or mechanism (pmdas still store it as char*'s,
> > resolution still done repeatedly and ambiguously), which represented
> > the bulk of the concern.
>
> I understood your concern, but I was then and remain now unconvinced
> of any genuine issues there.
Perhaps this will help.
Consider the following situation:
% docker run --name=SUBSTRING1 --hostname=FOO1 -i --rm sleep $RANDOM &
% docker run --name=SUBSTRING2 --hostname=FOO2 -i --rm sleep $RANDOM &
% docker run --name=SUBSTRING3 --hostname=FOO3 -i --rm sleep $RANDOM &
% ... and more, coming and going
... while pcp monitoring:
pmval --container=SUBSTRING pmcd.hostname
# but current pmda code (?) appears to work once,
then
# cache the result, even if no containers at all
stay running
pmval --container=SUBSTRING network.interface.inet_addr
# but current pmda code crashes
pmcd(31340) Error: ClientLoop: error sending Conn ACK PDU to new client
IPC protocol failure
pmcd(31340) Info: CleanupAgent ...
Cleanup "linux" agent (dom 60): protocol failure for fd=18, exit(0)
Since the code doesn't run well here, I'm unable to show an actual
transcript. But one can read code (e.g., up and down the call chain
from container_enter_namespaces() in pmdas/linux). So, according to
the current code/design, which of those SUBSTRING*y containers, coming
& going constantly, are pmval instances supposed to track? With the
container-name-lookup being done *at every fetch*, it's a coin toss -
and that is absurd. (More cases were outlined in the January
comments.)
Using container-name substrings as though they were a reliable &
persistent identifier is an error.
> Arguing about it then, as now, is sure to be counter-productive, and
> time is precious.
This is unacceptable.
- FChE
|