-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exec and other operations should support a default container #4355
Comments
Is the idea to change all calls to io.fabric8.kubernetes.client.dsl.internal.PodOperationContext#withContainerId(String containerId) to use the first containerId from an internal collection of container IDs? I don't know any of the internals and likely wouldn't be helpful in creating a pr but still am curious. Thanks for opening the issue! |
The logic would roughly be - if a containerId is not set, get the deployment and use the first container name as the id. If there's a concern about backwards compatibility with how we're currently doing things, then we'll only use the first container when there are multiple - probably just need to check the kubectl logic for consistency. |
👍
What are the possible user cases to be handled? Perhaps something like:
|
Just the first one is what is currently problematic wrt user expectations. kubectl defaults to the first container, the fabric8 client does not. However a narrow fix just for exec may not be the most appropriate - there are a lot of locations where a container may be specified so we'll need to determine all the places were defaulting is applicable. |
I thought this was already implemented (we do have something like this on JKube for Watch and Log operations).
Summary of
|
What is the impact of this issue if I have two (Jenkins pipeline defined) containers, the first is called jakartaeetck-ci and the second is called james-mail. Please assume that my first container With the fix applied, will the first container always be considered the main application and other containers always be considered sidecars? Is this the right terminology? |
Is your enhancement related to a problem? Please describe
kubectl if you don't specify the container argument will assume the first container for operations like exec. This may be leading to confusion / errors such as #4353 and #4319
Describe the solution you'd like
Similar to kubectl the fabric8 client should default to the first container when working with a multi-container pod.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: