#Retries and Multi-tenancy

1 messages · Page 1 of 1 (latest)

white vector
#

Hey everyone — we’re building an on-prem model deployment workload and comparing Dagger and Prefect. Two things holding us back are retries and multi-tenancy. Curious whether either of you has thoughts on whether Dagger supports these features or if we’d need to build them ourselves.

white vector
#

thoughts on this @bitter panther @waxen fulcrum 🙏

atomic pumice
#

@white vector on the topic of retries: it's come up before, and every time we concluded that "retry" is not something that can be universally implemented at the platform layer. It always encodes some application-specific logic. So we focus on making it very easy to implement your own retry logic

#

For example, if you have flaky tests, you'll want to temporarily enable retries for those tests. But if you implement a blanket retry for all tests, then you're wasting resources re-running failed tests that are not flaky

#

Simiarly, you may want a retry when connecting to a third-party service - for deployment, artifact upload etc. In that case you probably want each dagger function to implement its own retry there too

#

One thing we could do, is implement support for flaky tests. That could be very interesting

#

We have a new native Check type, so we could build flakiness support on that

white vector
#

Thanks, @atomic pumice — that’s helpful! I’m also curious whether you’ve thought about state management and multi-tenancy.

atomic pumice
white vector
#

@atomic pumice 1) multi-tenancy - if we want isolation, eg, Perfect has Workspaces, RBAC built in 2) state management if we want to track each call, get the previous version

white vector
#

thoughts @atomic pumice

bitter panther