Add option to run follow + label

[gabrielsvinha]

What this PR does / why we need it:
Remove check for follow + selector when running kubectl logs -l -f

Which issue(s) this PR fixes
Fixes #52218

[k8s-ci-robot]

@gabrielsvinha: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: GabrielSVinha
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: smarterclayton

Assign the PR to them by writing /assign @smarterclayton in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/kubectl/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dims]

/ok-to-test

[gabrielsvinha]

/assign @smarterclayton

[gabrielsvinha]

/release-note-none

[ereslibre]

I have a comment regarding this feature. This patch won't work as-is (unless I'm wrong) because when you reach:

kubernetes/pkg/kubectl/cmd/logs.go

Line 297 in 10b8665

_, err = io.Copy(o.Out, readCloser)

on the first pod, this operation will block, and you won't follow the rest of the pod logs, only the first one. I started to work on this yesterday, and I have something very similar:

master...ereslibre:follow-selector

However, I wanted to take more things into account before submitting a PR. Meaning: what happens if in the process of following a selector logs (e.g. kubectl logs -f -lapp=myapp) its pods are modified (e.g. killed because of a liveness probe and brought back). In this case, the patch I have won't work either, I don't know if that's within the scope of kubectl logs or we just want to ignore those edge cases. When you follow a specific pod in current kubernetes and it dies, you lose the follow and the process ends (obviously), but with a selector there's two viable options:

1. Ignore whatever happens in the future. We only follow the set of pods that matched the selector at the time of triggering the logs command.
2. While you are following the logs, keep track of the pod changes and follow those too if new pods appear.

I think a simple approach could be the ideal case first, but as said, this PR won't actually follow a set of pods correctly because it'll lock on the first one.

[dixudx]

I don't think this really does implement this.

[dixudx]

Agree with @ereslibre. This PR does not really implement this feature.

[k8s-ci-robot]

@gabrielsvinha: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dims]

/uncc

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.