Add support for the Launch command suite in the new CLI

[taenin]

Example commands:

oumi launch status
oumi launch which
oumi launch up --config foo
oumi launch run --config foo
oumi launch down --cluster a --cloud b
oumi launch stop --cluster a --cloud b --id c

Towards OPE-500 and OPE-473

[linear]

OPE-500

OPE-473

[wizeng23]

Besides changing oumi-launch to oumi launch, is there any other differences for how to specify the command? Ex. for oumi train in the other PR, the omegaconf CLI overrides had to be specified differenty.

I assume there'll be documentation checked in at some point?

[wizeng23]

For ease of review, is there any significant difference in logic between this PR and oumi/src/oumi/launch.py?

[taenin]

Besides changing oumi-launch to oumi launch, is there any other differences for how to specify the command? Ex. for oumi train in the other PR, the omegaconf CLI overrides had to be specified differenty.

I assume there'll be documentation checked in at some point?

You're correct, the main change is how additional params are passed. At some point (soon) we'll update this documentation. For now, here's a concrete example using oumi train:

What we have now:

oumi-train \
    "data.train.dataset.0.dataset_name=yahma/alpaca-cleaned" \
    "data.train.dataset.0.preprocessing_function_name=alpaca" \
    "data.train.dataset.target_col=prompt" \
    "model.model_name=microsoft/Phi-3-mini-4k-instruct" \
    "model.trust_remote_code=true" \
    "training.trainer_type=TRL_SFT/" \
    "training.output_dir=train/"

After my changes:

oumi train \
    --data.train.dataset.0.dataset_name yahma/alpaca-cleaned \
    --data.train.dataset.0.preprocessing_function_name alpaca \
    --data.train.dataset.target_col prompt \
    --model.model_name microsoft/Phi-3-mini-4k-instruct \
    --model.trust_remote_code true \
    --training.trainer_type TRL_SFT/ \
    --training.output_dir train/

[taenin]

For ease of review, is there any significant difference in logic between this PR and oumi/src/oumi/launch.py?

Nope, it's almost entirely the same. The only minor shift is from using a threadpool -> a process pool for polling jobs.