Quota و Reservation

1. مسئله‌ای که این درس مالک آن است

Quota، Reservation و Admission سه چیز متفاوت‌اند. Quota می‌گوید یک Scope حداکثر تا چه سقفی حق مصرف دارد؛ Reservation بخشی از ظرفیت را برای یک Owner/Window نگه می‌دارد؛ Admission تصمیم می‌گیرد یک Request مشخص، در زمان مشخص، با شواهد فعلی پذیرفته شود یا نه. این درس فقط همین مرز را مالک است و Resource Broker Metadata یا Chargeback را جذب نمی‌کند.

2. خروجی قابل تحویل

خروجی شما Quota, Reservation & Admission Ledger v1 است. هر تصمیم باید از فیلدهای قابل مشاهده بازسازی شود: quota_limit, quota_used, quota_remaining, lifecycle رزرو، capacity_allocatable, request_quantity, contention_state, admission_state, override_authority و evidence_ref.

3. مدل ذهنی: سه دفتر جدا

دفتر Quota درباره entitlement است، دفتر Reservation درباره commitment زمانی و مالکیت است و دفتر Admission درباره درخواست جاری. اگر این سه را یک Counter کنیم، یا ظرفیت را oversell می‌کنیم یا درخواست سالم را بی‌دلیل block می‌کنیم.

4. قرارداد شواهد

هر ردیف Ledger باید Scope و Resource Type را مشخص کند و مقدارهای Quota، Reservation، Capacity و Request را جدا نگه دارد. Reservation بدون reservation_expiry یا release_condition برای تصمیم مثبت کافی نیست. Capacity ناشناخته نیز با Quota مثبت به AVAILABLE تبدیل نمی‌شود.

5. Quota چه چیزی را ثابت می‌کند و چه چیزی را نه

در Kubernetes، ResourceQuota مصرف تجمیعی Namespace را محدود می‌کند، اما مستقل از ظرفیت واقعی Cluster است. پس quota_remaining=6 فقط می‌گوید از سقف entitlement شش واحد جا مانده است؛ نمی‌گوید شش GPU واقعاً اکنون قابل تخصیص‌اند.

6. Reservation را با تاریخچه اشتباه نکن

Reservation رکوردی با Owner، Quantity، Start، Expiry و Release Condition است. وقتی رزرو منقضی شد، تعهد فعال صفر می‌شود، اما رکورد تاریخی حذف یا بازنویسی نمی‌شود. حذف تاریخچه باعث می‌شود بعداً نتوانیم بفهمیم چرا ظرفیت در یک Window قبلی unavailable بوده است.

7. الگوریتم Admission

ترتیب تصمیم این است: ۱) Evidence معتبر است؟ ۲) Quota headroom کافی است؟ ۳) Active Reservationها از Capacity کم شده‌اند؟ ۴) Capacity باقیمانده Request را پوشش می‌دهد؟ ۵) اگر Exception لازم است، Override Authority ثبت شده؟ نتیجه می‌تواند ADMITTED, ADMITTED_OVERRIDE, QUEUED, REJECTED یا یک State شواهدی مثل HOLD/UNKNOWN/DISPUTED/STALE/BLOCKED باشد.

8. Baseline کارشده

دو Venture هر کدام Quota هشت GPU دارند ولی ظرفیت واقعی ده واحد است. Venture A چهار واحد تا ساعت 23:00 رزرو کرده و Venture B قبلاً دو واحد مصرف کرده و درخواست شش واحد دارد. برای B، quota_remaining=6 است. Capacity بعد از رزرو فعال A نیز 10-4=6 است؛ بنابراین Request شش‌واحدی قابل ADMITTED است. هم‌زمان مجموع Quotaها 16 است و از Capacity 10 بیشتر؛ پس contention_state=ENTITLEMENT_OVERBOOKED باقی می‌ماند.

9. چرا افزایش Quota ظرفیت نمی‌سازد

اگر Quota B را از 8 به 12 افزایش دهیم ولی Capacity همان 10 و Reservation فعال A همان 4 بماند، Headroom شاید 10 شود اما Capacity آزاد فقط 6 است. درخواست 8 واحدی باید QUEUED یا رد شود؛ افزایش Quota به‌تنهایی Reservation یا Physical Capacity ایجاد نکرده است.

10. Expiry و Release

Active Reservation از Timestamp تصمیم محاسبه می‌شود. اگر رزرو ساعت 19:00 تمام شده و Request ساعت 20:00 رسیده، نباید آن را همچنان چهار واحد committed حساب کرد. اگر Ledger هنوز 4 نشان دهد، State باید DISPUTED شود تا lifecycle reconcile شود.

11. Override اضطراری

Override یک bypass بی‌ردپا نیست. Request ممکن است از Quota عادی عبور کند فقط وقتی Scope، مقدار Exception، زمان، دلیل و override_authority ثبت شده باشند و Capacity واقعی هنوز اجازه دهد. Urgency هرگز Authority تولید نمی‌کند؛ Override بدون Authority = BLOCKED.

12. شواهد ناقص و منفی

capacity_allocatable=None یعنی UNKNOWN، نه available. Reservation بدون Expiry یا Release evidence یعنی HOLD. Evidence قدیمی یعنی STALE. reported reserved total ناسازگار با lifecycle یعنی DISPUTED. این Stateها شکست سیستم نیستند؛ مانع تصمیم قوی‌تر از شواهد می‌شوند.

13. Transfer: انقضای زودتر + Venture سوم

در Transfer، رزرو A زودتر منقضی می‌شود و Venture C برای Request شش‌واحدی، Quota عادی چهار واحد دارد اما Override دوواحدی با Authority ثبت‌شده می‌گیرد. Active Reservation اکنون صفر است، Capacity آزاد 10 است، effective quota به 6 می‌رسد و نتیجه ADMITTED_OVERRIDE است. تاریخچه رزرو A همچنان حفظ می‌شود.

14. Lab و روش اجرا

وارد lab/ARC-004-LAB1/learner/ شوید و python run_checks.py را Offline اجرا کنید. هشت Fixture شامل Baseline، Quota-only false confidence، expired reservation mismatch، unknown capacity، override بدون authority، stale evidence، missing expiry و Transfer است. تصمیم را از Output حفظ نکنید؛ Gate شکسته را توضیح دهید.

15. ارزیابی، Freshness و مرز ادعا

ارزیابی چهار بخش دارد: boundary، ساخت Baseline Ledger، تشخیص mutation و Transfer. منابع Kubernetes فقط FACTهای Quota/Capacity/Scheduling را محدود می‌کنند. State machine، lifecycle policy و Override gate طراحی MAKNOW هستند. هر تغییر مادی در semantics منابع باید در نسخه جدید Package requalify شود، نه با تغییر Silent همین Golden.