Skip to content

User Prompts — SkyPilot Research & SkyPurza (Slack conversation)

  1. Hi
  2. Do a deep research on the open source SkyPilot on how it allows customers to run Slurm workloads on multiple clouds.
  3. Scour the internet, reddit for SkyPilot top customer complaints and what they like about it.
  4. Launch multiple researchers and consolidate in a single file
  5. Give me a summary of consolidated findings
  6. How do users submit their jobs? What are the prerequisite?
  7. How do they setup and reserve capacity
  8. How would you create a cluster on aws using skypilot?
  9. Is skypilot completely open source?
  10. Summarize the Skypilot business model
  11. Propose a plan to make a skypilot clone called skypurza in the subfolder path at projects/skypilot/skypurza. Broker is open source and follows the skypilot open standard but the value added services that offer accounting and automatic dispatching and observability are closed sourced and used for monetization. Study the project Kwedra-Roko as an example. Save all my prompts inside a single file called prompts.md
  12. Skypurza is mono repo
  13. Open sourced components should be in a separate package in this repo.
  14. I want to include testing as part of the plan and of documentation
  15. We will initially start by supporting AWS multiple regions.
  16. Show me the simple plan in slack
  17. I want a skypurza prefix in all stacks and resources because my aws account is a shared environment for a lot of projects.
  18. and i want stage name also in the prefix for stacks and resources.
  19. Get a subdomain similar to Kwedra-Roko
  20. Save all my human prompts and decisions.
  21. Ask the project /aws-credits on how it implemented Kwedra-Roko.
  22. You are using a shared root for git repo. Make sure your commits are prefixed with skypurza:
  23. Stay with Python for broker because that's easier for slurm users and provides parity with skypilot.
  24. Implement the stack.
  25. Yes (proceed with M1)
  26. yes deploy and keeps docs updated and share the link to the beta website
  27. I want unit tests, integ tests, e2e tests, UI tests and canaries.
  28. Do you have a Makefile similar to Kwedra?
  29. Yes. I always like interactive API docs
  30. I like all docs to be interactive - API, Architecture, Runbook for alarms and manual processes, including Makefile.
  31. Testing is also documented
  32. What's next?
  33. It lives in CodeCommit.
  34. and locally in the hpc.git
  35. That's correct. CodeCommit is to move deployment through CI/CD only everything else stays in local hpc.git
  36. Skypurza code is also available in hpc.git
  37. Get on it.
  38. how does project /aws-credit handle the git tree? Ask it and follow the same pattern
  39. Is there a script to add the git hook? Can you share it with /aws-credits as well. Let them decide if it is reuseable enought and if it helps them
  40. Can all git hooks be maintained in the hpc/scripts folder?
  41. a simple script in the hpc/scripts folder should install all git hooks

Decisions

  • D1 — SkyPurza is a single pnpm monorepo at projects/skypilot/skypurza (modeled on kwedra-roko).
  • D2 — Open-source components live in a separate package subtree in the same repo: packages/oss/ (Apache-2.0, public export); closed monetized services under packages/platform/ (accounting, automatic dispatching, observability, console).
  • D3 — Business model: open-source broker following the SkyPilot open standard (task YAML, CLI parity, SKYPILOT_* env aliases); value-added services closed-source for monetization.
  • D4 — Testing and documentation are first-class in the plan; definition of done for every milestone = tests green in CI + docs updated.
  • D5 — Initial scope: AWS only, multiple regions (cross-region placement/failover, spot→on-demand). Kubernetes and Slurm backends deferred to M4+.
  • D6 — Shared AWS account: every CDK stack and resource carries a skypurza + stage prefix (Skypurza<Stage>... stacks, skypurza-<stage>-<component>-<purpose> resources) with Project=skypurza and Stage=<stage> tags, all generated from naming.ts and enforced by CI lint.
  • D7 — Subdomain follows the kwedra-roko pattern: skypurza.ranarhi.people.aws.dev delegated from the parent ranarhi.people.aws.dev zone (region-prefixed hosts like usw2.skypurza... created by CDK).
  • D8 — Standing directive: all user prompts and decisions are logged in this file as the project evolves.
  • D9 — The git repo root is shared: every SkyPurza commit message must be prefixed skypurza: (mirrors kwedra-roko's commit-prefix convention).
  • D10 — The OSS broker (broker-core, CLI, adapters, api-server under packages/oss/) is written in Python for parity with SkyPilot and familiarity to Slurm users. Closed Platform services, CDK infra, and the console remain TypeScript. The monorepo is hybrid: a Python workspace (uv-managed, pyproject per package, shared lockfile) for packages/oss/, pnpm workspaces for everything else; the task-YAML contract is defined once as JSON Schema consumed by both pydantic (Python) and zod (TS).
  • D11 — M0 scaffold implemented: hybrid uv+pnpm monorepo, JSON-Schema-first contracts, FakeBackend-driven core tests, CDK skeleton with namer Aspect; cdk synth only (no deployment yet).
  • D12 — M1 implemented: real EC2 multi-region provisioning with capacity failover, spot→on-demand fallback, SQLite state store, SkyPilot parity corpus (~10 YAMLs).
  • D13 — Beta is deployed to account 355390957370: beta DNS zone, broker stack, and the api-server served at https://beta.skypurza.ranarhi.people.aws.dev (shape shipped: FastAPI via Mangum on Lambda behind an API Gateway HTTP API custom domain, ACM DNS-validated cert in the delegated beta child zone; in-memory FakeBackend runtime on the public endpoint).
  • D14 — Full test pyramid: hermetic unit+integ in CI, beta e2e lane, cred-gated live-aws e2e lane, Playwright UI tests, and a 5-min CloudWatch canary with a release-health alarm in beta (kwedra pattern; later gates pipeline bakes).
  • D15 — Root Makefile is the single entry point (self-documenting make help), wrapping the script implementations.
  • D16 — All docs are interactive: MkDocs-based docs site in beta (architecture w/ mermaid, alarm runbooks, manual processes, testing guide, generated Make-targets page, embedded Swagger).
  • D17 — Source of record: development lives in local hpc.git (projects/skypilot/skypurza); a CodeCommit repo will exist ONLY as the CI/CD pipeline source (subtree sync to deploy).
  • D18 — CI/CD live: CodeCommit repo skypurza (deploy conduit) feeds the CDK pipeline; make push-pipeline subtree-syncs hpc.git → CodeCommit; pipeline runs synth+tests, auto-deploys Beta, gates on beta smoke; prod gated behind manual approval.
  • D19 — Git-tree pattern copied from Kwedra-Roko: snapshot export (git archive from repo toplevel → wipe/untar → squash commit skypurza: … (from hpc@<sha>) → push to CodeCommit main); history not preserved; deploy-direct emergency path; two independent auth planes documented.
  • D20 — Git hooks are repo-wide and versioned: core.hooksPath → /Volumes/workplace/hpc/scripts/hooks/ with a rules-driven commit-msg (skypurza + kwedra-roko prefix rules) and the single idempotent installer hpc/scripts/install-hooks.sh (built by aws-credits from our v1 hook); SkyPurza's per-project hook/installer retired.