odo logs --follow should not break if no containers are running

[valaparthvi]

/kind bug

What versions of software are you using?

Operating System: Fedora 32

Output of odo version: odo v3.0.0-beta3 (66fbfe0bf)

How did you run odo exactly?

1. mkcd /tmp/10
2. odo init
3. odo logs --follow

Actual behavior

$ odo logs --follow
no containers running in the specified mode for the component "devfile-nodejs-deploy" 

Expected behavior

If the component is not running on the cluster, it should wait until odo logs --follow there is some data to print until user exits.

Related to #5716
cc: @feloy

Any logs, error output, etc?

[valaparthvi]

I think odo logs --follow was implemented the way kubectl logs has been implemented, that's why it fails.
But to enhance it, we could make it function the way odo dev does, as a long running process. In case of error, we can wait until good logs are received or ask the user to hit Ctrl+c and exit.

[valaparthvi]

Working on it as a part of #5716

[dharmit]

Actual behavior

$ odo logs --follow
no containers running in the specified mode for the component "devfile-nodejs-deploy" 

This behaviour is intentional. A user using odo logs or odo logs --follow wants to see the logs for containers running in both Dev and Deploy modes. But until odo dev or odo deploy are executed, there are no containers running in either of the modes. Hence, the message you see there.

IMO, just because user specified --follow doesn't mean odo should behave smartly and wait till the user executes odo dev or odo deploy in a different terminal.

Expected behavior

If the component is not running on the cluster, it should wait until odo logs --follow there is some data to print until user exits.

IMO, no. That's just trying to fix a problem that doesn't exist, and make odo unnecessarily too smart.

Probably I'm biased because I worked on this. But trying to make odo too smart has always seemed unappealing to me. My bias apart, is this something we discussed as a problem that needs to be changed before starting to work on it as a part of the mentioned issue/PR?

I think odo logs --follow was implemented the way kubectl logs has been implemented, that's why it fails.

odo logs is using the same underlying libs and functions as kubectl logs. Plus, the part "that's why it fails" is subjective. As I said, the behaviour is intentional.

But to enhance it, we could make it function the way odo dev does, as a long running process. In case of error, we can wait until good logs are received or ask the user to hit Ctrl+c and exit.

I'm going to blow the same old trumpet here - why do we want to enhance it? The way I see it, it's not even enhancement, but adding smartness and maintenance overhead. Has any user suggested that this is a flawed behaviour/approach. If yes, I'll shut up. If no, I don't understand why, as engineers, we want to make odo so smart about various things instead of keeping things simple.

Probably my biases are screaming here, but I'm strongly opinionated about consciously keeping things simpler rather than making a tool too smart!

[feloy]

Actual behavior

$ odo logs --follow
no containers running in the specified mode for the component "devfile-nodejs-deploy" 

This behaviour is intentional. A user using odo logs or odo logs --follow wants to see the logs for containers running in both Dev and Deploy modes. But until odo dev or odo deploy are executed, there are no containers running in either of the modes. Hence, the message you see there.

IMO, just because user specified --follow doesn't mean odo should behave smartly and wait till the user executes odo dev or odo deploy in a different terminal.

Expected behavior

If the component is not running on the cluster, it should wait until odo logs --follow there is some data to print until user exits.

IMO, no. That's just trying to fix a problem that doesn't exist, and make odo unnecessarily too smart.

Probably I'm biased because I worked on this. But trying to make odo too smart has always seemed unappealing to me. My bias apart, is this something we discussed as a problem that needs to be changed before starting to work on it as a part of the mentioned issue/PR?

I think odo logs --follow was implemented the way kubectl logs has been implemented, that's why it fails.

odo logs is using the same underlying libs and functions as kubectl logs. Plus, the part "that's why it fails" is subjective. As I said, the behaviour is intentional.

But to enhance it, we could make it function the way odo dev does, as a long running process. In case of error, we can wait until good logs are received or ask the user to hit Ctrl+c and exit.

I'm going to blow the same old trumpet here - why do we want to enhance it? The way I see it, it's not even enhancement, but adding smartness and maintenance overhead. Has any user suggested that this is a flawed behaviour/approach. If yes, I'll shut up. If no, I don't understand why, as engineers, we want to make odo so smart about various things instead of keeping things simple.

Probably my biases are screaming here, but I'm strongly opinionated about consciously keeping things simpler rather than making a tool too smart!

We want this enhancement to be able to use it for odo dev --logs.

The problem we encounter while implementing odo dev --logs is that the logs module works only when the pods are already running.

I can see different solutions to be able to use this module for odo dev --logs:

• either wait for all pods to be running before to start the logs module
• or make the logs module reactive and be able to wait and detect new running pods

We have chosen to explore the second solution first as it seems the more robust in an asynchronous environment.

[dharmit]

I can see different solutions to be able to use this module for odo dev --logs:

• either wait for all pods to be running before to start the logs module

• or make the logs module reactive and be able to wait and detect new running pods

We have chosen to explore the second solution first as it seems the more robust in an asynchronous environment.

OK. I don't have a strong preference for either. Let's do whichever makes sense. But the side effect it's going to have on current behaviour of odo logs --follow should be well communicated, and we should make it a conscious choice. While going through this issue, it didn't seem like current behaviour of odo logs --follow was really an issue in itself, except that we couldn't reuse code for odo dev --logs. Not being able to reuse code is OK.

Anyway, apologies if I seem to have deviated from the topic.

[kadel]

bumping priority because this is blocker for #5716