Minimum `PodRun`

[Synicix]

struct RunInfo {
    name: String,
    image: String,
    created: u64,
    terminated: Option<u64>,
    env_vars: HashMap<String, String>,
    command: String,
    state: RunState,
    mounts: Vec<String>,
    labels: HashMap<String, String>,
    cpu_limit: f32,
    memory_limit: u64,
}


struct PodRun<'orch, T> {
    pod_job: PodJob,
    orchestrator: &'orch T,
}

trait PodRunAPI {
    fn new(
        pod_job: PodJob,
        orchestrator: &Self::Orchestrator,
    ) -> Result<PodRun<Self::Orchestrator>>;
    fn get_info(&self) -> Result<RunInfo>;
    fn get_result(&self) -> Result<PodResult>;
    async fn get_result_async(&self) -> Result<PodResult>;
}

[guzman-raphael]

Will likely require revisiting list_model since the standard flow of creating a PodRun won't include annotation info. That would break with the current requirement that annotation must be present on save_model.

[guzman-raphael]

Summary from 11/23/24 - 11/27/24 meetings:

• PodRun: Provides a handle to access info for an on-going PodJob run. Created by Orcapod's orchestrator.
• pod_run = orchestrator.start(pod_job: PodJob) will return a detached, immediate, synchronous PodRun.
• PodRun will have an asynchronous method called .get_result_async() which can be used with the await syntax. For example in your own asynchronous method you could do pod_result = await orchestrator.start(pod_job).get_result_async().
• To make it blocking in synchronous code, we could either instruct user to simply use pod_run = tokio_runtime.block_on(orchestrator.start(pod_job).get_result_async()) or we could offer a wrapper for this e.g. .get_result_sync().

[guzman-raphael]

After discussion, we have concluded that it is best to redefine this issue as a minimal PodRun implementation (see updated description). Resource metrics feature has been moved to its own dedicated issue.