Nataneljpwd commented on PR #59413: URL: https://github.com/apache/airflow/pull/59413#issuecomment-3866512510
> > I have to agree with what @potiuk and @SameerMesiah97 said here, we would not want such a change where all pods are deleted, even if they are orphan pods, maybe a good idea might be to allow to configure the states of the pods to be deleted rather than choose for the client, I think it can be done without much complexity while preserving current behavior > > So you would want to replace the existing flags with a set of flags for the deletion of the pods in each state? Like this: > > 1.`delete_running_pod` > 2.`delete_pending_pod` > 3.`delete_failed_pod` > 4.`delete_succeeded_pod` > > I believe a user could replicate the behaviour of the existing pods using these flags but if your suggestion involves deprecating the existing cleanup modes, then that would be a breaking change. This is not too much of a concern for `delete_active_pod` as that was recently introduced but `delete_pod`,` keep_pod` and `succeeded_pod` are likely being used by many deployments. No, I do not propose deprecating current behavior, rather, I proposed to add a `delete_by_states` method which allows to delete pods by the respective states which the user provides > I think what you suggested is the ideal set of options as it allows maximum configurability by users and avoids us having to decide what combination of pods to delete for each mode is appropriate. If you have an approach that minimises parameter bloat and preserves backwards compatibility, I’m all ears. As written above, I have added clarity to my proposes approach > One possible approach would be to add just one parameter (maybe call it `delete_pods_in_phase`), which accepts a list/set/dict of valid pod phases. Pods that are in any of the valid phases are deleted, regardless of the cleanup mode selected. Naturally, this would be an override parameter meant for advanced users. Yes, this is exactly what I proposed -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
