You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After reading this page and trying the code examples, there are some open questions:
What's the difference between the primary and default containers? Is the default container really a Flyte concept?
If a user needs to override the Task container name using a Runtime PodTemplate, how it can be achieved if the use of primary as the base container spec seems to be prescripted?
It should be clear that while there's a hierarchy for applying PodTemplates, the watch does not need a deafult-pod-template-name to be set. Even with a namespace-specific PodTemplate, the controller should start the watch
Probably code examples have to be revisited to make sure that the restrictions to merge lists (like the containers section) are considered. Using the code example here leads to the controller ignoring all the spec config and using the default.
Are you sure this issue hasn't been raised already?
Yes
Have you read the Code of Conduct?
Yes
The text was updated successfully, but these errors were encountered:
Difference between primary and default containers: The primary container is the main container that must complete for the task to be considered complete. The default container serves as a base configuration for all containers in the Pod. The default container is a Kubernetes concept, not specific to Flyte (source).
Overriding Task container name: To override the Task container name using a Runtime PodTemplate, you can specify the primary_container_name in the PodTemplate. This allows you to define a custom name for the primary container (source).
Hierarchy for applying PodTemplates: The hierarchy for applying PodTemplates is well-defined, and the watch does not require a default-pod-template-name to be set. Namespace-specific PodTemplates are sufficient for the controller to start the watch (source).
Code examples and list merging restrictions: Code examples should be revisited to ensure that list merging restrictions, such as the containers section, are considered. Incorrect configurations can lead to the controller ignoring the spec and using the default configuration (source).
Description
After reading this page and trying the code examples, there are some open questions:
primary
anddefault
containers? Is thedefault
container really a Flyte concept?primary
as the base container spec seems to be prescripted?watch
does not need adeafult-pod-template-name
to be set. Even with a namespace-specific PodTemplate, the controller should start the watchcontainers
section) are considered. Using the code example here leads to the controller ignoring all the spec config and using the default.Are you sure this issue hasn't been raised already?
Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: