Bring your towel and join one of the fastest growing data communities. Welcome to our second-generation open source orchestration platform, a completely rethought approach to dataflow automation.

Prefect Community

Upgrading to Prefect 2.0 - is there a good guide on how to convert a working `ECSRun` `run_config` and turn it into one of the new `ECSTask` blocks?  Looks like the arguments got rearranged a lot.

We rewrote this from scratch to try to solve longstanding complaints about ECS in Prefect 1

I’d recommend using the `ECSWorker` as we’ll probably deprecate `ECSTask` in favor of that in the near future

I actually just got the `ECSTask` working, so not actually this sec!  Unless you've got some example code handy for `ECSWorker` (I don't see any in the docs?)

Oh!  <@U01CEUST9B5> Is there a Best Practice when it comes to when to make new Infra blocks vs Overrides?  For instance, should I make a new Block for each Instance Type I wanna spin up?  (`r6i.large` or whatever, which means a different Capacity Provider and all kinds of nonsense). Or should I just have 1, and then put Overrides in the Flow definition?

The old way I used to do it, we had code that manipulated Python dictionaries and passed it to `ECSRun` - ideally there'd be a similar workflow!

There’s just <https://prefecthq.github.io/prefect-aws/ecs_worker/> for the worker right now — it’s meant to be more UI driven.

For creating new blocks vs overrides, it’s kind of personal preference and depends on how many fields you’re going to override. I originally intended for more blocks to be created but it turns out people often just want to tweak a couple items without registering a new block so we introduced the overrides.

You can use `ECSTask.parse_obj(options)` if you want to use Pydantic to parse a dictionary.