Skip to content

docs(gpudevice): propose class-attributed GPU usage - #130

Open
Aleksei Sviridkin (lexfrei) wants to merge 1 commit into
mainfrom
design/gpudevice-class-usage
Open

Aleksei Sviridkin (lexfrei) wants to merge 1 commit into
mainfrom
design/gpudevice-class-usage

Conversation

@lexfrei

Copy link
Copy Markdown
Contributor

This proposes two changes of course in the GPU proposal, both raised in the review of the step 1 API in cozystack/cozystack#4998. Both records are Proposed and become Accepted when this merges.

0019 makes the usage record carry the class a VM was admitted with. Today a class must own its resource name, because billing maps a Workload record back to a class through that name. The implementation had to record the owner in status.ownedResourceName to keep that working when resourceName changes. With the class in the record, two classes can share a resource name, the recorded owner and ResourceNameConflict go away, and a licensed class can sit next to a bring-your-own-license class on one vGPU profile. The record also answers the three questions from the review: why the owner was recorded state, what happens when status is lost, and why duplicates fail closed. It lists who can and cannot set the class on a usage record.

0020 drops tolerationSeconds from class tolerations before the kind is released. A finite toleration reaches the launcher pod and evicts the VM after it was placed, and the design does not need it.

Before review

  • If this revises a merged design proposal: it adds a decision record under that proposal's decisions/ directory, or says below why none is needed.

Both are decision records under gpudevice, linked from its Decisions section.

DCO

  • Commits are signed off (git commit --signoff).

The implementation of step 1 added recorded resource-name ownership
to keep the unique name a usage record is mapped through. Carrying the
admitted class into the usage record removes the need for uniqueness,
and the record answers the review questions about the recorded owner.

A second record proposes dropping tolerationSeconds from class
tolerations before the kind is released, since a finite toleration
evicts the VM after it is placed.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>
@coderabbitai

coderabbitai Bot commented Nov 10, 2026

Copy link
Copy Markdown

Important

  • Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: defaults
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: a7734eec-02ab-4f27-b02e-1f86713e1a16
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant