Skaffold: Ignore some containers in logs

[dgageot]

I'm using Skaffold to develop an application deployed on Istio. The logs from all those istio-proxy containers are a complete distraction.

It would nice to be able to filter them out but adding some config in the skaffold.yaml.

[dgageot]

@r2d4 do you think I should add a log section in the skaffold.yaml? I seeking for ideas. I don't really know where to put it

[jonjohnsonjr]

Is grep -v not sufficient for this? :P

[dgageot]

:-) It does work. That's how I currently do it. But it removes the logs of the cleanup phase that happen after the SIG_PIPE signal is sent.

[nathanph]

I think I'd like to see a log section in the skaffold.yaml.

Some things that have annoyed me in no particular order are:

• Missing important logs from the start of a helm deployment.
• Logging in containers/pods that I don't want it to.
• Not logging in containers/pods that I want it to.
• Helm pod names being really long.

[nkubala]

I'm a +1 on a log section in the config as well. Probably makes sense to have a container whitelist rather than a blacklist. Anybody interested in sending a PR?

[corneliusweig]

@nkubala I'd like to pick up the new log section for custom pod selectors. My current idea is to have a new top-level config section like

log:
  # a list of deployment.spec.selector items, rules are OR'ed
  - matchExpressions: # in one item, rules are AND'ed
      - key: XY
        values: ['val1', 'val2']
        operator: In NotIn Exists DoesNotExist
    # or
    matchLabels: # in one item, rules are AND'ed
      tail: "true"

When unset, it needs to default to

log:
  - matchLabels:
      tail: "true"

so that all skaffold-deployed artifacts are log-tailed.

[nkubala]

this is still definitely an issue with skaffold and one that we don't really have a solution for. @corneliusweig drove some great conversations about customizing log tailing, but in the process we discovered just how complex of an issue this is and didn't come to a resolution.

I still think it would be great to add support for this, but realistically our team can't work on this any time soon. I'll drop the priority to a P3 but still keep it open.