garden icon indicating copy to clipboard operation
garden copied to clipboard

`garden exec` and `garden logs` wrongly target sidecar containers

Open isaacpz opened this issue 2 years ago • 3 comments

Bug

Current Behavior

garden exec and garden logs always target the first container configured in a pod. Sometimes, sidecar containers are auto-injected. When this happens, garden exec and garden logs become useless because they target the sidecar container instead of the main application container.

Since Kubernetes 1.18, we can use the kubectl.kubernetes.io/default-container annotation to configure this behavior for kubectl exec and kubectl logs. However, garden does not respect this annotation.

Expected behavior

garden exec and garden logs always target the application container.

Reproducible example

  1. Deploy a container module
  2. Have some other service inject a sidecar container (I am experimenting with osiris)
  3. Run garden exec or garden logs
  4. Observe that commands target the sidecar container instead of the container managed by Garden

Workaround

None

Your environment

  • OS: macOS
  • How I'm running Kubernetes: EKS garden version 0.12.42

isaacpz avatar Jul 07 '22 06:07 isaacpz

Hi @isaacpz—thanks for the suggestion! We'll have a look.

thsig avatar Jul 07 '22 09:07 thsig

@isaacpz does the same issue happen if you use kubernetes module type?

vvagaytsev avatar Aug 09 '22 13:08 vvagaytsev

I have not tested with the kubernetes module type

isaacpz avatar Aug 23 '22 03:08 isaacpz

This issue has been automatically marked as stale because it hasn't had any activity in 90 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

stale[bot] avatar Jan 07 '23 22:01 stale[bot]

This issue has been automatically marked as stale because it hasn't had any activity in 90 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

stale[bot] avatar May 21 '23 20:05 stale[bot]

@isaacpz Thanks again for reporting the issue.

In Garden Bonsai (v0.13), the logs behavior has been revamped and now garden logs should show logs from all containers (including original container as well as the sidecar containers). I just verified that with a simple configuration for both container type as well as Kubernetes type for the [demo-project](https://github.com/garden-io/garden/tree/main/examples/demo-project) example by injecting a simple busybox container.

garden logs

➜  demo-project git:(main) ✗ garden logs --follow
Debugger listening on ws://127.0.0.1:9229/a26d84e3-8343-4248-9356-c4405d2b2712
For help, see: https://nodejs.org/en/docs/inspector
Logs 📜

ℹ garden               → Running in Garden environment local.default
ℹ providers            → Getting status...
✔ providers            → Cached (took 0.6 sec)
ℹ providers            → Run with --force-refresh to force a refresh of provider statuses.
ℹ graph                → Resolving actions and modules...
✔ graph                → Done (took 0.1 sec)

Service logs (from the last '1m' for each service):
───────────────────────────────────────────────────────────────────────────────────────
ℹ [monitors]           → Starting log monitor for Deploy type=container name=backend...
ℹ [monitors]           → Starting log monitor for Deploy type=container name=frontend...
backend → Server running...
backend → hello_from_2nd_busybox
2023-07-14T13:04:29.023145551Z hello_from_2nd_busybox
2023-07-14T13:04:34.021835303Z hello_from_2nd_busybox

So please give it a try with latest version of Garden and let us know if it is still an issue.

However, regarding garden exec, that'll be addressed with #4838.

shumailxyz avatar Jul 14 '23 14:07 shumailxyz

@isaacpz the fix has been released in 0.13.9, please try it out.

vvagaytsev avatar Jul 20 '23 10:07 vvagaytsev