Update pod-migration.mdx#700
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
danstotts-ops
left a comment
danstotts-ops
left a comment
There was a problem hiding this comment.
Nice speed on this, draft structure is right. Two things to settle before this merges, plus a process guard:
-
Do not merge until the feature-flag ramp. Everything documented here ships dark behind the migration_* flags, which ramp to 100% together around Aug 18 (POD-133). Merging to main publishes to production docs immediately, six weeks before users can see any of this behavior. Recommend converting this PR to draft (or adding a do-not-merge label) and merging when Javier confirms flags are at 100%.
-
The mover pod description looks like it describes two pods where the design has one. Per POD-121/POD-123, the target pod itself is deployed at 0 GPUs as the CPU mover (usesCpuMover), and on completion its original GPU count is restored and it becomes your migrated pod. It is not removed. The current draft has both 'the target may temporarily show 0 GPUs' and a separate 'temporary CPU mover pod... once the migration completes, it is removed automatically', which reads as two different pods. Worth confirming the exact behavior with Javier and collapsing steps 1-2 and the Note into the one-pod story.
-
'You are not charged for it' may need qualifying. POD-122 sets billingExempt for admin/system-initiated migrations, and POD-121 scopes the MVP to admin-initiated. If user-initiated migrations are not billing-exempt in the MVP, the flat claim overpromises. Also one to confirm with Javier.
Related: the R5 terminate/stop guard has an open design question (hard-block vs force-override, POD-128), so the error copy documented here could still change before ramp.
2 participants
No description provided.