Support multiple containers for pod logs

Problem to solve

In https://gitlab.com/gitlab-org/gitlab-ee/issues/12819, we discovered that the pod log feature doesn't work on pods with more than one container. As a short-term fix, we decided to show the first container by default. But, we should allow users to see all of the containers and to select which one they want to see the log for.

Intended users

Further details

Design proposal

After the user clicks through to a specific pod log from the environments page, they will now see a containers dropdown in addition to the environment and pod dropdowns:

Permissions and Security

Documentation

Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Links / references

added devopsmonitor typefeature + 1 deleted label

marked this issue as related to #12819 (closed)

We discussed needing this follow-up issue in today's backlog grooming session. I've added it, and will start thinking about designs.

cc: @adriel, @mnohr, @kencjohnston

I've added the proposed design into the issue description. Also looping @dhershkovitch in since he has joined since this comment was originally posted!

When we implemented the environment dropdown, we realized that we would ultimately need a searchable dropdown as the number of environments could be quite large. Presumably this is also the case for containers?

When we implemented the environment dropdown, we realized that we would ultimately need a searchable dropdown as the number of environments could be quite large. Presumably this is also the case for containers?

Yes, the number of containers is greater than the number of pods

Okay, great. So we'll likely need a searchable dropdown for containers, as well. I don't know if this can happen as a first pass or if we'll need to add a simple dropdown, much like we have for environments and pods, as a first pass and go back through and add a searchable dropdown as a second iteration. I'm guessing it would look odd for us to add a searchable dropdown for pods, when we haven't yet added a searchable dropdown for the other two yet. Perhaps we can go back through and update all of the dropdowns in one go?

@mrincon - you've worked on the previous issues, do you have a sense of the order in which this work should occur?

added UX label

mentioned in issue #13462 (closed)

changed milestone to %12.6

added 1 deleted label

added Enterprise Edition label

added [deprecated] Accepting merge requests label

assigned to @ameliabauerly

removed [deprecated] Accepting merge requests label

changed the description

changed milestone to %Backlog

changed milestone to %12.6

added Category:Logging label

added release post item label

mentioned in issue #6502 (closed)

added to epic &1348 (closed)

changed epic to &2113

Based on our discussions in the weekly meeting, this will need both frontend and backend work. For the backend we will need to create a new API.

added backend frontend labels

At some point we will need to make the drop-downs searchable as well. @jivanvl had more information from the frontend side. Do we need a new issue to track this as it is something separate from this issue.

We shouldn't need to open a new issue, we just need to figure out what's the dropdown component that rest of the frontend team uses, so we're not circling back and forth with the implementation when it reaches to reviewers/maintainers

So apparently we do have a component, but it's not currently available to be used outside of an internal GitLab feature, there's a gitlab-ui issue about porting that component to our component library so it can be used everywhere.

Should we grab that issue so we can include searchable dropdowns as part of our logging vision?

gitlab-ui#416 (closed)

cc @dhershkovitch

That seems like a great idea, @jivanvl. WDYT about adding this issue to our 12.6 list of work, @dhershkovitch and @adriel, so that we can utilize this dropdown variant for our log and metrics pages?

@ameliabauerly Looking at the gitlab-ui issue looks like the component functionality has been merged and it's only missing some styling, there's a merge request for that here: gitlab-ui!896 (merged)

I think if all goes well, we should be able to start working on adding those dropdowns to the logs feature fairly soon

Since I believe the design piece doesn't require additional discussion, I'll mark this workflow:ready for development. If that's incorrect, though, just let me know!

removed UX label

added workflowready for development label

assigned to @akohlbecker

added Deliverable label

assigned to @mrincon

mentioned in issue #34021 (closed)

@akohlbecker One question, can this be supported by kubernetes API? Or does it only apply to es logs?

Yes, this is supported by k8s

@dhershkovitch I think using the elasticsearch logs solution will solve this use case for users at #5696 (closed), should we keep this issue open for kubernetes API? Is this still relevant?

I think the feature should become part of the "escape hatch", I suggest we move it to the next milestone.

@mrincon - As far as I know, right now, people who don't utilize ES can only view the first container's logs. They have no way of switching between containers.

Regardless of how the list view off of Operations > Pod Logs develops for those who have ES enabled, those who don't have ES installed will still need to be able to switch between containers. Given this, it seems like this issue is still necessary so that those with only Kubernetes logs enabled can switch between containers. Unless I'm misunderstanding something? Definitely let me know if I am!

Overall, it seems like this is something we could do relatively easily that would pretty dramatically improve usability for those not using ES, so it seems like something we may as well move forward with?

@ameliabauerly. @akohlbecker @mrincon Moving this to the next milestone as we agreed that Elasticsearch is our default logging experience

changed milestone to %12.7

changed milestone to %Backlog

unassigned @mrincon

removed Deliverable label

unassigned @akohlbecker

mentioned in issue #31105 (closed)

mentioned in issue #207015 (closed)

unassigned @ameliabauerly

Removing myself as an assignee as this is "ready for development" and as I'm now focusing on Health.

cc: @nadia_sotnikova

added [deprecated] Accepting merge requests label

closing, duplication

closed

added grouprespond label and removed 1 deleted label