Conversation
…pdate Co-Authored-By: Alec Fong <alecsanf@usc.edu>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
README.md
Outdated
| - **NVIDIA Cloud Partners (NCPs)** looking to offer Brev-compatible GPU compute | ||
| - **Infra teams** building cluster-aware systems or abstractions on raw compute | ||
| - **Cloud providers** interested in contributing to a shared interface for accelerated compute | ||
| - **Compute brokers & marketplaces (aggregators)** offering multi-cloud compute; use `Location`, `SubLocation`, and `CloudProviderID` to differentiate upstream sources behind a consistent interface |
There was a problem hiding this comment.
we dont need to go into implementation detail here i like just "Compute brokers & marketplaces (aggregators) offering multi-cloud compute". Lets remove other stuff in this file that we added
docs/how-to-add-a-provider.md
Outdated
| - Provider (CloudProviderID): Identify your aggregator (e.g., "mybroker"). If you expose underlying vendors, include that metadata on the returned resources (e.g., via tags/labels) or encode it in stable IDs that you control. | ||
| - Location and SubLocation: Map upstream regions/zones into `Location` and `SubLocation` so users can choose placement consistently across sources. For example, use `Location="us-west"` and `SubLocation="vendorA/zone-2"` or `SubLocation="sv15/DC3"` for finer placement. | ||
| - InstanceType IDs: If upstream vendors don’t provide stable, cross-market IDs, generate stable IDs using `MakeGenericInstanceTypeID` and include upstream hints in IDs or metadata. Ensure stability over time to avoid breaking consumers. | ||
| - Capabilities: Only advertise features that your aggregator reliably supports across upstream vendors (e.g., Create/Terminate/Reboot). Omit capabilities (ModifyFirewall, Stop/Start, ResizeVolume, MachineImage, Tags) if they are not uniformly supported. |
There was a problem hiding this comment.
Actually the capabilities represent all the features the broker could support. Instead we can use instance type attributes to delineate behavior. there even is a "provider" attribute on the instance type that you can use.
docs/how-to-add-a-provider.md
Outdated
| - InstanceType IDs: If upstream vendors don’t provide stable, cross-market IDs, generate stable IDs using `MakeGenericInstanceTypeID` and include upstream hints in IDs or metadata. Ensure stability over time to avoid breaking consumers. | ||
| - Capabilities: Only advertise features that your aggregator reliably supports across upstream vendors (e.g., Create/Terminate/Reboot). Omit capabilities (ModifyFirewall, Stop/Start, ResizeVolume, MachineImage, Tags) if they are not uniformly supported. | ||
|
|
||
| Minimal pattern: |
There was a problem hiding this comment.
lets remove the following sections theres no need.
…utes and simplify README bullet Co-Authored-By: Alec Fong <alecsanf@usc.edu>
|
Addressed feedback:\n- Removed capability-restriction guidance for brokers; clarified that capabilities reflect what the broker can support, and to express differences via InstanceType attributes (including the 'provider' attribute).\n- Removed the minimal pattern/example/design notes from the aggregator section.\n- Simplified README bullet to a concise audience line for brokers/marketplaces.\n\nCI is green. Please let me know if you'd like any additional tweaks. |
1 participant
docs: add compute brokers/marketplaces guidance and README audience update
Summary
Added documentation for compute brokers, marketplaces, and multi-cloud aggregators.
Links
Notes