AgitatedDove14
I do believe triggers should be unique somehow because I find them way too easy to mishandle. Especially if used with schedule_function which is defined in the same script. Updating that function requires deleting the existing trigger task first and recreating it. If not done like this you just end up with 2 trigger tasks with the same name which I assume will respond to the same event(s) but do something slightly different in response. I assume it might work like this because I did not actually try it. I don't think an event can be consumed only by one consumer. I guess what I would expect to happen when I run the py script with an updated schedule_function is only for that function to be updated in place. But I understand that since this is also a clearml task, like everything else, it does need to play by the same rules. I know you can have a TriggerScheduler defined and add multiple task_triggers to it and all that will run in a single pod. Is it possible to have multiple TriggerScheduler defined in the same script with start_remotely and all the TriggerScheduler will run on the same pod?
Hello CostlyOstrich36 I solved it by using a .sh script locally when I want to create/update the trigger. The sh script will chain 2 py scripts together. The first py script will take care of deleting the existing running trigger task and the second py script will be the one that will recreate the trigger task with the updated code.
It just seems strange to me that you could have 2 triggers that do different things but using the same name. Nothing that can't be worked around but for automation I don't think creating a TriggerScheduler with an existing name should be allowed. Anyway, these checks can be implemented outside of the clearml capabilities.
It also sucks a bit that each TriggerScheduler will run in it's own pod in kubernetes.
Hi DangerousDragonfly8 , can you please elaborate on your use case? If you want only a single instance to exist at any time how do you expect to update it?
Nothing that can't be worked around but for automation I don't think creating a TriggerScheduler with an existing name should be allowed
DangerousDragonfly8 I think I understand , basically you are saying the fact a user can create two triggers with the same name can create some confusion ?
It also sucks a bit that each TriggerScheduler will run in it's own pod in kubernetes.
Actually this depends on how you spin it, and you can actually spin a a service agents running multiple triggers inside a single pod (to save in resources), wdyt?
