When I switched a Deploy action of type Kubernetes...
# 🤖|ask-kapa
f
@microscopic-river-74022 When I switched a Deploy action of type Kubernetes from using local manifests to a Kustomization living in a remote configuration repository, my tests running as
kubernetes-exec
began failing to target the specified
containerName
, instead defaulting to a different container. I fixed this by setting a default container annotation on the Deployment, but this feels like a hack. Is this a known issue?
m
Please stand by @fresh-yak-35965 as I search the knowledge base. I normally take about 15 seconds or so. :wave:
---------------------- This is an interesting issue you've encountered. While I don't have specific information about this exact scenario in the provided knowledge sources, I can offer some insights based on related information. The behavior you're describing does sound unusual and potentially problematic. Garden typically allows you to specify a
containerName
for targeting specific containers in multi-container pods. This is supported in various contexts, including
kubernetes-exec
tests, as evidenced by the kubernetes-exec Test reference (). However, the switch from local manifests to a remote Kustomization shouldn't inherently change how Garden targets containers. It's possible that this change is affecting how Garden interprets or applies the container specifications. A few points to consider: 1. Make sure your
kubernetes-exec
test configuration correctly specifies the
containerName
under the
spec.resource
section. 2. Check if your Kustomization is modifying the pod or container specifications in a way that affects container naming or ordering. 3. The
defaultTarget
configuration in Kubernetes Deploy actions can be used to specify a default container for various operations. You might want to review this setting in your Deploy action configuration. Reference: defaultTarget () 4. Your workaround of setting a default container annotation on the Deployment is a valid approach recognized by Kubernetes, but you're right that it shouldn't be necessary if Garden is configured correctly.
Given the complexity of this issue and the lack of specific information about interactions between remote Kustomizations and container targeting in the provided knowledge sources, I would recommend: 1. Double-check all relevant configurations to ensure they're correct after the switch to remote Kustomization. 2. If the issue persists, it would be worth reporting this to the Garden team as a potential bug or unexpected behavior. The Discord thread you mentioned earlier suggests that the Garden team is responsive to such reports and interested in investigating unusual behaviors. Remember, when making significant changes to your Garden configuration or source management, it's always a good idea to review and test all components of your setup to ensure they still work as expected. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
message has been deleted