I'm not sure that unedited version would be useful in audio-only format and I don't think either of us would have time to edit it. If someone would volunteer...
I wish I was here live to ask this question but I will ask anyway: How could these tools help with workload right-sizing in the case of Argo Workflows? These pods are extremely transient and their resource requests are driven from the WorkflowTemplate CR, so I am unsure how these can be automatically optimised. This probably also goes deeper as jobs typically run workloads which complete faster with more resources, but this relationship isn't linear so there's always a sweet spot. It's a different problem to solve than service workloads.
You would need to start differentiating argo workflow pods based on the projects they are in charge of. Runs for the same project are probably consuming similar amount of resources.
@@DevOpsToolkit the way I see it working is the people developing their workflows run iterations across a range of resource requests and utilise the runtime data to tune it. As a platform engineer I could provide this tooling but it largely seems like a static, predefined affair.
@DryBones111 i think that the point is that it should not be static but adapt to specific needs. As far as I observed, very few know what a container or an app needs and even if they do those needs change over time so the only path forward is to have a mechanism to deduce that at runtime and adjust.
Agree with Victor here, there would need to be labels that are consistent between multiple runs to be able to tune the workload even if it has a unique name each time it runs, as long as there is a consistent label the data can be re-used for similar runs. Where some of the automatic rightsizing tools are operating as a mutating webhook it doesn't matter what the WorkflowTemplate CR defines for resources it will be overwritten at scheduling time by the webhook.
It this show available on Spotify?
Would like to hear with no ads and while the app is closed (and to not pay for another premium subscription… 😅)
I'm not sure that unedited version would be useful in audio-only format and I don't think either of us would have time to edit it. If someone would volunteer...
I wish I was here live to ask this question but I will ask anyway:
How could these tools help with workload right-sizing in the case of Argo Workflows? These pods are extremely transient and their resource requests are driven from the WorkflowTemplate CR, so I am unsure how these can be automatically optimised.
This probably also goes deeper as jobs typically run workloads which complete faster with more resources, but this relationship isn't linear so there's always a sweet spot. It's a different problem to solve than service workloads.
You would need to start differentiating argo workflow pods based on the projects they are in charge of. Runs for the same project are probably consuming similar amount of resources.
@@DevOpsToolkit the way I see it working is the people developing their workflows run iterations across a range of resource requests and utilise the runtime data to tune it. As a platform engineer I could provide this tooling but it largely seems like a static, predefined affair.
@DryBones111 i think that the point is that it should not be static but adapt to specific needs. As far as I observed, very few know what a container or an app needs and even if they do those needs change over time so the only path forward is to have a mechanism to deduce that at runtime and adjust.
Agree with Victor here, there would need to be labels that are consistent between multiple runs to be able to tune the workload even if it has a unique name each time it runs, as long as there is a consistent label the data can be re-used for similar runs. Where some of the automatic rightsizing tools are operating as a mutating webhook it doesn't matter what the WorkflowTemplate CR defines for resources it will be overwritten at scheduling time by the webhook.