@benm/joris,
here's the user scenario in my mind:
1. master offers resources to the framework, e.g. 2 cpu
2. framework launch a task (2 cpu) and mark the task/executors as throttleable
3. in ResourceEstimator, it should only consider the throttleable task/executors:
- keep enough resources for the tasks/executors without throttleable flag/attribute
- report allocated but not used resources by task/executor with throttleable flag/attribute; for example, report 1 cpu as "Revocable.Throttleable" resources to framework in this case
4. it's up to framework to use which resources; "Revocable.Throttleable" means it'll share compress resources with resources owner, "Revocable" (without ThrottleableInfo) means it'll be evicted when the resources owner reclaimed it back
5. QoS Controller makes sure:
- enough resources for the tasks/executors without throttleable flag/attribute
- if used resources exceed allocated resources with throttleable flag/attribute, evict the task/executor on revocable resource
So to @connor's question, maybe a flag/attribute to task/executor when launching it. Regarding the name, both "ScavengeInfo"/ "BestEffortInfo"/"ThrottleableInfo" are OK for me, maybe "ScavengeInfo" is better.
Any comments?
For this scenario, I think there're still open questions:
1. Can framework launch task with throttleable flag/attribute on revocable resources?
2. For ResourceEstimator/QoS Controllor, should Agent double check it report?
3. What's the behaviour between the two container: the container on original resouces & the container on revocable resource?
4. Who handle compressible/in-compressible resources? Maybe ResourceEstimator/QoSController, it should not report in-compressible resources as Revocable.Throttleable.