Projects

Overview

The course project is a semester-long, team-based systems project, and it is the largest single component of your grade. Each team works on a realistic cloud or distributed systems problem proposed and supervised by a mentor — typically an industry engineer, a researcher, or a senior graduate student. Projects usually run on real infrastructure, such as a commercial public cloud or a research cloud.

Unlike a problem set, a project has no predetermined answer. You will scope the problem yourself, decide what to build, and then be held to the plan you set. The emphasis is on building something that runs, measuring it honestly, and being able to convince someone else that your results are real.

The project runs on the following schedule:

Date Milestone
09/02 Project list released; mentors introduced in class
09/06 Project preferences due
09/09 Teams announced; meet your mentor
09/23 Demo 1 — design proposal
10/21 Demo 2 — working prototype
11/16 Demo 3 — optimized system
12/09 Final presentation

Teams have been assigned. Six of the seven projects listed below are running. magnum-ui functional testing is not running this semester: it drew little interest in the preference form, and the team originally assigned to it asked to move to Keystone-NG instead. Everyone who submitted the preference form got their first or second choice. Your team, your mentor, and your repository are in the pinned Piazza post.

How matching worked. You did not pick your own team. The project list went up before the first lecture, mentors were introduced in class on 09/02, and you ranked every project on the preference form due 09/06. Teams were assigned from those rankings and announced on 09/09.

Project List

Each project is proposed and mentored by an engineer or researcher from industry or a national lab. These six are running this semester; the full proposal for each one is linked from its title, and the repository is public, so you can read any team’s work.

  • Build-Bench Challenge: Autonomous LLM Agents for Cross-Architecture Package Repair (Markdown)
    Mentor: Minghua Ma, Microsoft.
    Repository: ec528-fall26/build-bench
    Build an autonomous LLM agent that repairs software packages whose builds fail when migrated across x86_64, ARM, and RISC-V. The team submits a qualified agent to the ICSE 2027 Build-Bench Challenge.
    Expects: Python, Linux/Git/Docker, and at least one member with LLM agent frameworks and one with build systems (CMake, Make, Autotools, Debian, RPM).

  • Load Modeling and Load Balancing Simulation Platform
    Mentor: Shripad Nadgowda, Meta.
    Repository: ec528-fall26/load-balancing
    Build a platform that models steady-state request routing across a large fleet and answers “what-if” questions — what happens to utilization if request load grows, or if the balancing policy changes from round-robin to least-connection.
    Expects: Python, C, or Go, and at least one member comfortable with containers/microservices, KV stores such as Redis, and SQL databases such as Postgres.

  • Zero Trust Cryptographic Confinement for AI Agents
    Mentor: Charles Munson, MIT Lincoln Laboratory.
    Repository: ec528-fall26/zero-trust
    Build an end-to-end pipeline where an AI agent’s request to execute a workload is paused, cryptographically approved by a multi-signature quorum, and only then deployed onto a remotely attested VM on the Mass Open Cloud.
    Expects: at least one member with Python, Go, or Rust and one with a basic understanding of PKI and digital signatures. Experience with VMs, the MOC, or Keylime is valuable.

  • Computational Storage
    Mentors: Alex Merenstein, Vasily Tarasov, and Anthony Hsu, IBM.
    Repository: ec528-fall26/comp-storage
    Layer a compute tier on top of an existing storage system so data is processed where it lives, rather than copied out and back. The team builds a serverless-style interface for arbitrary file operations plus a background format-conversion service, and measures both against a copy-process-copy-back baseline.
    Expects: Linux command line for everyone, and at least one member with Python. Familiarity with containers or serverless is valuable; you will work with Kubernetes, Ceph, and Parquet.

  • Highly Available Object Storage Development
    Mentor: Andressa Cabistani, Red Hat — OpenStack Swift.
    Repository: ec528-fall26/swift
    Swift is a highly available, distributed, eventually consistent object store that lets organisations keep large amounts of data safely and cheaply. Work on the storage layer itself.
    Expects: Python. Scope and milestones are still being finalised with the mentor.

  • Keystone-NG: OpenStack Identity and Access Management in Rust
    Mentor: Artem Goncharov — OpenStack Keystone.
    Repository: ec528-fall26/keystone-ng
    Modernise OpenStack’s IAM with OIDC, password-less login and SCIM, written in Rust. The goal is to bring features that are hard to implement in Python to the community and show what Rust buys them.
    Expects: Rust (required for at least one member) and a working understanding of authentication and authorisation.

Not running this semester

Seven projects were offered and six run. This one is not going ahead, with thanks to the mentor for proposing it.

  • magnum-ui Functional Testing
    Mentor: Michal Nasiadka — OpenStack Magnum.
    magnum-ui currently has no functional test coverage. Build a test suite that exercises it end to end using devstack together with Selenium or Playwright.
    Expects: Python.

Important Documentation

Document Purpose
Grading Grading policy and the rubrics used for every deliverable
Project Setup and Submission Repository setup, submission branches, and deadlines

Groups

Projects are done in teams of 4-5 students. You did not pick your own team: teams were assigned from the ranked preferences submitted by 09/06 and announced on 09/09. There are six teams this semester.

Every team member is expected to contribute technically. Two parts of your grade are individual rather than team-wide — the Presentation component and the Individual contribution component — so a team cannot carry a member who does not participate, and a strong contributor is not dragged down by a weak team.

Getting Started

Now that teams are announced:

  1. Send us your GitHub username. Use the form linked from the pinned Piazza post, by Friday 09/11. We need it to give you push access; until then you can read your repository but not push to it.
  2. Meet your mentor. Agree on a regular meeting time. Mentors are volunteers with day jobs, so schedule early and be reliable.
  3. Clone your team repository. It is already created for you in the course GitHub organization, from the course template. Push a trivial commit in the first week to confirm you have access.
  4. Scope the work and write your design proposal. Decide what you are actually going to build and what milestones you commit to for each demo. This document is due in the repository at Demo 1 and is what your progress is graded against for the rest of the semester.
  5. Start building as soon as the design is settled. Demo 1 is a proposal, but Demo 2 four weeks later expects a prototype that runs end to end.

Version Control

All teams use git, hosted on GitHub. Each team has one repository, and it is the single source of truth for the project.

Commit as you work rather than in a single dump before each deadline. Your commit history is the evidence that the team worked steadily, and it is one of the inputs to the Individual contribution score.

Grading

Project work accounts for 70% of your final grade: 50% for the team project, 10% for your individual presentation, and 10% for your individual contribution to the team. Progress is graded against the milestones your own team commits to, not against other teams. The final artifact is graded the way a top-tier conference evaluates artifacts — we will run your code and check that your claimed results reproduce. So turn in something that runs, and do not claim a result we cannot reproduce. The grading policy page lists detailed information about how grading is done.

Submission

Everything your team produces for this course lives in your team’s GitHub repository: the design proposal, demo slides, design documents, demo videos, source code, and the final report. There is no separate submission system.

Each deliverable is due at 12:00 noon on the day of the corresponding class, in a branch named for that deliverable (demo-1, demo-2, demo-3, final-demo). We take an automatic snapshot of that branch at the deadline and grade exactly what is in it. See Project Setup and Submission for the full mechanics.

Late Policies

There are no late hours, no late days, and no late tokens. A deliverable that is not in the correct branch at 12:00 noon on the deadline receives no credit for that deadline.

Cheating and Collaboration

You are expected to build your project yourselves. The following are not permitted:

  • submitting code, text, or results your team did not produce and presenting them as your own,
  • copying another team’s work,
  • fabricating or selectively reporting experimental results, and
  • publicly posting your project in a way that lets a future team submit it as their own.

The following are permitted and encouraged:

  • using existing open-source systems, libraries, and frameworks as components of your project, provided you say clearly which parts are yours and which are not,
  • discussing designs, approaches, and debugging with other teams, and
  • asking your mentor, the TA, or the instructor for help at any point.

Because the reproducibility component is graded by running your code, overstating a result is worse than reporting a modest one. An honest negative result costs you very little. A claim we cannot reproduce costs you a great deal.