Skip to content

README.md

Latest commit

 

History

History
187 lines (152 loc) · 10.6 KB

README.md

File metadata and controls

187 lines (152 loc) · 10.6 KB

BEPs

Backend.AI Enhancement Proposals

Process

  1. Reserve a BEP number by adding your proposal to the BEP Number Registry table below.
  2. Create a new branch and pull request for creation.
    • Copy proposals/BEP-0000-template.md to create a new document with your reserved number.
    • Write and submit the draft.
  3. Discuss with other developers and maintainers in the PR.
  4. Submit multiple pull requests to modify and update your proposals.
  5. Once accepted, update the document status to "Accepted" with the target version.
    • You may further submit additional pull requests to revise the document when there are changes required found during actual implementation work.
  6. Once implementation is complete, update the status to "Implemented" with the actual version.

Status Lifecycle

Draft ──────→ Accepted ──→ Implemented
  │              │
  └─→ Rejected ←─┘
Status Description
Draft Initial proposal, under discussion
Accepted Approved for implementation, target version assigned
Implemented Implementation complete, actual version recorded
Rejected Proposal was rejected or cancelled

Status Transition Rules

From To When Required Actions
Draft Accepted Proposal approved by maintainers Set Target-Version
Draft Rejected Proposal rejected after discussion Document rejection reason
Accepted Implemented Implementation merged to main Set Implemented-Version
Accepted Rejected Implementation cancelled Document cancellation reason

Version Fields

BEP documents track three version milestones:

Field When to Fill Example
Created-Version When first creating the BEP 26.1.0
Target-Version When status changes to Accepted 26.2.0
Implemented-Version When status changes to Implemented 26.2.1

Version format: YY.Sprint.Patch (e.g., 26.1.0 = Year 2026, Sprint 1, Patch 0)

Writing Guide

For section structure, Decision Log lifecycle, AI context blocks, and document segmentation details, see the /bep-guide skill.

Quick Reference

  1. Copy proposals/BEP-0000-template.md
  2. Fill metadata (Author, Status, Created, Created-Version)
  3. Write sections in order: Motivation → Current → Proposed → Migration → Plan
  4. Submit PR on branch bep/XXXX-short-title

BEP Number Registry

To prevent number conflicts, always reserve your BEP number here first before creating the document. When multiple people add entries simultaneously, Git merge conflicts will naturally prevent duplicate numbers.

BEP numbers start from 1000.

Number Title Author Status
1000 Redefining Accelerator Metadata Joongi Kim Draft
1001 App Injection Joongi Kim Draft
1002 Agent Architecture HyeokJin Kim Draft
1003 Test Scenario for Agent Functionality Bokeum Kim Draft
1004 Scenario Tester HyeokJin Kim Draft
1005 Unified AppProxy Kyujin Cho Draft
1006 Service Deployment Strategy Jeongseok Kang Accepted
1007 Storage Agent Joongi Kim Draft
1008 RBAC HyeokJin Kim Draft
1009 Model Serving Registry HyeokJin Kim Draft
1010 New GQL - Accepted
1011 (skipped)
1012 RBAC (detailed) Sanghun Lee Draft
1013 GraphQL Schema for New Model Service Bokeum Kim Accepted
1014 Preemption of Low Priority Sessions Joongi Kim Draft
1015 Keypair/User/Project Resource Policy Reorg Joongi Kim Draft
1016 Accelerator Interface v2 Joongi Kim Draft
1017 Model Scanner and Downloader Bokeum Kim Accepted
1018 Local Cache for Model VFolders Joongi Kim Draft
1019 MinIO Artifact Registry Storage Gyubong Lee Accepted
1020 VFolder Destination Support for Artifact Import Gyubong Lee Draft
1021 GQL StringFilter Enhancement HyeokJin Kim Implemented
1022 Pydantic Field Metadata Annotation HyeokJin Kim Implemented
1023 UnifiedConfig Consolidation & Loader/CLI HyeokJin Kim Draft
1024 Agent RPC Connection Pooling HyeokJin Kim Implemented
1025 Server-Side CSV Export API HyeokJin Kim Draft
1026 Fair Share Scheduler HyeokJin Kim Draft
1027 Docker Relay in Compute Sessions Joongi Kim Draft
1028 Kubernetes Bridge Daemyung Kang, Hyunhoi Koo Draft
1029 Sokovan ObserverHandler Pattern HyeokJin Kim Draft
1030 Sokovan Scheduler Status Transition Design HyeokJin Kim Draft
1031 GraphQL API Field Metadata Extension HyeokJin Kim Draft
1032 Unified Input Validation for REST and GraphQL HyeokJin Kim Draft
1033 Sokovan Handler Test Scenarios HyeokJin Kim Draft
1034 KernelV2 GQL Implementation Gyubong Lee Draft
1035 Distributed Request ID Propagation Gyubong Lee Draft
1036 Artifact Storage Usage Tracking and Quota Enforcement Gyubong Lee Draft
1037 Volume Host Availability Check Gyubong Lee Draft
1038 ImageV2 GQL Implementation Gyubong Lee Draft
1039 Image ID Based Service Logic Migration Gyubong Lee Draft
1040 Multiple Files Download in ZIP TaekYoung Kwon Draft
1041 Scope-Based GraphQL API Naming Convention HyeokJin Kim Draft
1042 MyPy Strict Mode Migration HyeokJin Kim Draft
1043 Scope Types Description Sanghun Lee Draft
1044 Multi-Agent Device Split Hyunhoi Koo Draft
1045 Prometheus Client Extraction and Querier Interface Abstraction BoKeum Kim Draft
1046 Unified Service Discovery with DB-backed Service Catalog HyeokJin Kim Draft
1047 Resource Slot DB Normalization HyeokJin Kim Draft
1048 RBAC Entity Relationship Model Sanghun Lee Draft
1049 Model Service Zero-downtime deployment architecture Gyubong Lee Draft
1050 Prometheus Query Preset System BoKeum Kim Draft
1051 Kata Containers Agent Backend Kyujin Cho Draft
1052 Scoped App Config Redesign Gyubong Lee Draft
1053 Native Session Retry Jeongseok Kang Draft
next (reserve your number here)

File Structure

Single-File BEP (< 500 lines)

For short proposals, use a single markdown file:

proposals/
└── BEP-1018-simple-proposal.md         # All content in one file

Segmented BEP (>= 500 lines)

When a BEP exceeds ~500 lines or covers 3+ distinct components, split into a main document + sub-documents. Each sub-document should represent one independent work unit.

Segmentation criteria (any one triggers):

  • Total document exceeds ~500 lines
  • Proposed Design has 3+ distinct components
  • Implementation Plan has 3+ independent phases
  • Document covers multiple subsystems
proposals/
├── BEP-XXXX-title.md              # Main: overview + motivation + index (< 200 lines)
└── BEP-XXXX/                     # Sub-documents and supporting files
    ├── component-a.md             # Component A detailed design (one work unit)
    ├── component-b.md             # Component B detailed design (one work unit)
    ├── migration.md               # Migration plan (if complex)
    └── diagrams/                  # Images, schemas

Directory naming rule: Use BEP number only (e.g., BEP-1002/), not the full title.

Registry link rule: Always link to the main .md file, not the directory.

Main document role: Concise entry point serving as overview — metadata, motivation, document index table, Decision Log, and Open Questions. Keep under ~200 lines.

Sub-document rules:

  • Each sub-document = one work unit (implementable independently)
  • Keep each under ~300 lines
  • Self-contained: include enough context to understand without reading others
  • Use descriptive file names: data-model.md, config-schema.md, event-registration.md
  • Cross-reference other sub-documents by relative link
  • Open Questions go in the main document only (single source of truth)

Supporting Files Only

For BEPs that are single-file but need images or schemas:

proposals/
├── BEP-1002-agent-architecture.md      # Main document (single file)
├── BEP-1002/                           # Supporting files only
│   ├── agent-architecture.png
│   └── kernel-flow.png
└── BEP-1012-RBAC.md                    # Main document (single file)

For detailed writing workflow, see /bep-guide skill.