I am proposing that we split the workload collection into Workload & Job
Workload
Workloads should only contain information related to deploying them on a host. Think of them as artifacts or a image that you can put on different hosts. Therefor they should only contain information related to the workload and everything it needs to run.
{
"manifest": {...},
"version": "0.0.1",
"system_specs": {}
}Job
A job is an active workload running on a host. It can contain information about the workload or the host it is running on. It's current state and the desired state that it needs to be.
{
"workload": ObjectId(workload_id),
"host": ObjectId(host_id),
"current_state": "Pending",
"desired_state": "Running",
"cpu_usage": 0.2,
"memory_usage": 128,
"disk_usage": 50
}Resoning
To me it seems more like we are modifying the worklaod to create a bandait solution rather than something that is more flexible and future proof.
If we want to report stats on each workload that is running on a host it will become very messy. Since one workload can be on multiple hosts. You would have to make an array for each host and map that data to a single workload. So the data model in mongodb could be alot simpler with this solution.
Also, most other tools and companies do something very similar. Think of docker with images and containers or github with artifacts and workloads. This seems like a pretty common distinction to make. I would also think of workloads as classes in most languages while jobs are more like instances of those classes
I am proposing that we split the workload collection into
Workload&JobWorkload
Workloads should only contain information related to deploying them on a host. Think of them as artifacts or a image that you can put on different hosts. Therefor they should only contain information related to the workload and everything it needs to run.
{ "manifest": {...}, "version": "0.0.1", "system_specs": {} }Job
A job is an active workload running on a host. It can contain information about the workload or the host it is running on. It's current state and the desired state that it needs to be.
{ "workload": ObjectId(workload_id), "host": ObjectId(host_id), "current_state": "Pending", "desired_state": "Running", "cpu_usage": 0.2, "memory_usage": 128, "disk_usage": 50 }Resoning
To me it seems more like we are modifying the worklaod to create a bandait solution rather than something that is more flexible and future proof.
If we want to report stats on each workload that is running on a host it will become very messy. Since one workload can be on multiple hosts. You would have to make an array for each host and map that data to a single workload. So the data model in mongodb could be alot simpler with this solution.
Also, most other tools and companies do something very similar. Think of docker with images and containers or github with artifacts and workloads. This seems like a pretty common distinction to make. I would also think of workloads as classes in most languages while jobs are more like instances of those classes