Scheduler Offer ReservationDistributed Systems & Databases

Task prompt

# Scheduler Offer Reservation ## Goal The containerized two-level resource scheduler in `/app/scheduler.py` has a flawed scheduling contract. A resource offer is currently treated as a non-binding proposal: once an offer is sent, the same resources may be offered to another framework, and the scheduler may rescind an offer after a framework has committed to launching a task. You must fix the scheduler so that it honors the two-level scheduling contract correctly. ## Deliverable Write a corrected `scheduler.py` to `/logs/artifacts/scheduler.py`. The verifier will import this module and run deterministic scenarios against it. Do not modify files under `/app`; only the artifacts under `/logs/artifacts/` are graded. ## Required API Implement a module `scheduler.py` with the following classes and methods: - `Scheduler(nodes, now=0)` `nodes` is a dict `node_id -> total_resources`. - `advance_time(delta)` Advance the internal clock by `delta`. - `make_offers(framework_id, timeout=10)` Return a list of `Offer` objects, one per node that has free capacity. - `accept_offer(framework_id, offer_id)` Accept a pending offer. Return `True` only if the offer is valid and the acceptance succeeds. - `launch_task(framework_id, offer_id, task_id=None)` Launch a task from an accepted offer. Return a `task_id` on success (use the provided `task_id` or generate one), or `None` on failure. - `decline_offer(framework_id, offer_id)` Release an offer so its resources can be offered again. - `set_node_resources(node_id, total)` Update a node's total capacity. - `get_allocations()` Return a dict `task_id -> (framework_id, node_id, resources)`. `Offer` objects must expose at least: - `offer_id` - `framework_id` - `node_id` - `resources` - `state` — one of `pending`, `accepted`, `declined`, `expired`, `invalidated`, `launched` ## Correctness requirements 1. **No over-commitment**: At all times, the sum of resources allocated to running tasks plus resources reserved by outstanding offers on any node must not exceed the node's total capacity. 2. **Exclusive offers**: Once resources are offered to one framework, they cannot be offered to another until the offer is declined, expired, invalidated, or launched. 3. **Launch confirmation**: A launch must be rejected if its offer has expired, was declined, was invalidated, or the node no longer has enough capacity. 4. **Progress**: Declined or expired resources must become available for future offers. ## Notes - Do not write a main program, tests, or extra files; only the scheduler module is graded. - Keep the API signatures compatible with the ones above. - Lines containing `TASK_BUNDLE_CANARY` are ignored by the verifier.