Conversation
WalkthroughThis pull request adds comprehensive documentation for Hardware Profile functionality in infrastructure management, covering introduction, workflows, configuration guides, and CLI-based creation procedures for managing hardware configurations in Kubernetes-based inference services. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~4 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@docs/en/infrastructure_management/hardware_profile/functions/hardware_profile.mdx`:
- Line 5: Update the document heading text that currently reads "Hardware
Profile Manage" to the corrected phrase "Hardware Profile Management" in the
heading line (the H1 that starts with "# Hardware Profile Manage") so the title
uses proper grammar; replace only the heading text and keep the surrounding
markdown syntax intact.
In
`@docs/en/infrastructure_management/hardware_profile/how_to/create_hardware_profile_cli.mdx`:
- Line 17: Update the prerequisite sentence that currently reads "You have a
namespace where you have permissions to view or create `HardwareProfile`
resources (typically a cluster-scoped resource or in a specific admin
namespace)" to state that `HardwareProfile` is a namespaced resource and users
must have permissions in the specific target namespace; reference the example
YAML's namespace (e.g., `namespace: kube-public`) as an example and remove the
"cluster-scoped" wording so the doc correctly requires namespace-level
permissions to view/create `HardwareProfile`.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5c407a22-b403-4c68-bdb7-0bd98f28d733
📒 Files selected for processing (8)
docs/en/infrastructure_management/hardware_profile/functions/hardware_profile.mdxdocs/en/infrastructure_management/hardware_profile/functions/index.mdxdocs/en/infrastructure_management/hardware_profile/how_to/cpu_and_gpu_profiles.mdxdocs/en/infrastructure_management/hardware_profile/how_to/create_hardware_profile_cli.mdxdocs/en/infrastructure_management/hardware_profile/how_to/index.mdxdocs/en/infrastructure_management/hardware_profile/how_to/schedule_to_specific_gpu_nodes.mdxdocs/en/infrastructure_management/hardware_profile/index.mdxdocs/en/infrastructure_management/hardware_profile/intro.mdx
| weight: 10 | ||
| --- | ||
|
|
||
| # Hardware Profile Manage |
There was a problem hiding this comment.
Fix heading grammar.
Line 5 should read Hardware Profile Management (not “Hardware Profile Manage”).
✏️ Suggested text change
-# Hardware Profile Manage
+# Hardware Profile Management📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Hardware Profile Manage | |
| # Hardware Profile Management |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/en/infrastructure_management/hardware_profile/functions/hardware_profile.mdx`
at line 5, Update the document heading text that currently reads "Hardware
Profile Manage" to the corrected phrase "Hardware Profile Management" in the
heading line (the H1 that starts with "# Hardware Profile Manage") so the title
uses proper grammar; replace only the heading text and keep the surrounding
markdown syntax intact.
|
|
||
| - You have access to a Kubernetes cluster with the platform installed. | ||
| - You have configured `kubectl` to communicate with your cluster. | ||
| - You have a namespace where you have permissions to view or create `HardwareProfile` resources (typically a cluster-scoped resource or in a specific admin namespace). |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, locate and read the documentation file
find . -name "create_hardware_profile_cli.mdx" -type fRepository: alauda/aml-docs
Length of output: 150
🏁 Script executed:
# Search for HardwareProfile CRD definitions in the repository
find . -type f \( -name "*.yaml" -o -name "*.yml" -o -name "*.json" \) | xargs grep -l "HardwareProfile" | head -20Repository: alauda/aml-docs
Length of output: 41
🏁 Script executed:
# Also search for any infrastructure-related CRD or API definitions
find . -path "*/infrastructure*" -type f \( -name "*.yaml" -o -name "*.yml" \) | head -20Repository: alauda/aml-docs
Length of output: 41
🏁 Script executed:
cat -n ./docs/en/infrastructure_management/hardware_profile/how_to/create_hardware_profile_cli.mdx | head -100Repository: alauda/aml-docs
Length of output: 3085
🏁 Script executed:
# Search for any references to infrastructure.opendatahub.io or CRD definitions in docs
rg "infrastructure.opendatahub.io|HardwareProfile|apiVersion" docs/en/infrastructure_management/ -A 2 -B 2Repository: alauda/aml-docs
Length of output: 4429
🌐 Web query:
OpenDataHub HardwareProfile CRD apiVersion scope namespaced
💡 Result:
The OpenDataHub HardwareProfile CRD has apiVersion: infrastructure.opendatahub.io/v1alpha1. It belongs to the group "infrastructure.opendatahub.io". The scope is Namespaced, as it is a standard Kubernetes CR created with kubebuilder without explicit Cluster scoping markers, used per-namespace for hardware configurations in Open Data Hub deployments. Plural name: hardwareprofiles, singular: hardwareprofile, kind: HardwareProfile.
Citations:
- 1: https://pkg.go.dev/github.com/opendatahub-io/opendatahub-operator/v2/api/infrastructure/v1alpha1
- 2: https://github.com/opendatahub-io/opendatahub-operator
- 3: https://opendatahub.io/docs/working-with-accelerators
🌐 Web query:
infrastructure.opendatahub.io HardwareProfile v1 vs v1alpha1
💡 Result:
HardwareProfile is a Custom Resource Definition (CRD) in the infrastructure.opendatahub.io API group used in Open Data Hub (ODH) for defining hardware configurations like accelerators, CPU, memory for scheduling workloads such as workbenches and model serving. v1alpha1 vs v1: - v1alpha1: This is the alpha version of the API, defined in github.com/opendatahub-io/opendatahub-operator/v2/api/infrastructure/v1alpha1. It includes types like HardwareProfile, HardwareProfileSpec with fields for identifiers (CPU, Memory, Accelerator), scheduling spec (Queue or Node, with Kueue or node selectors), etc. GroupVersion: infrastructure.opendatahub.io/v1alpha1. - v1: Referenced in the PROJECT file at github.com/opendatahub-io/opendatahub-operator/blob/main/PROJECT as path: github.com/opendatahub-io/opendatahub-operator/v2/api/infrastructure/v1 version: v1 for kind: HardwareProfile. This appears to be the stable version, likely with refinements over v1alpha1 for production use. E2E tests cover both versions. No detailed schema for v1 found in searches, but the progression from v1alpha1 to v1 follows Kubernetes API versioning (alpha to stable). Official docs describe HardwareProfile usage without specifying version, managed via ODH dashboard (Settings > Hardware profiles). Similar to ODH's DataScienceCluster upgrade from v1alpha1 to v1. Differences likely include API stabilizations, validation rules, or additional fields in v1, but core purpose remains defining hardware specs for targeted scheduling with identifiers, resource limits, tolerations, node selectors.
Citations:
- 1: https://pkg.go.dev/github.com/opendatahub-io/opendatahub-operator/v2/api/infrastructure/v1alpha1
- 2: https://github.com/opendatahub-io/opendatahub-operator/blob/main/PROJECT
- 3: https://github.com/opendatahub-io/opendatahub-operator/blob/main/README.md
- 4: https://opendatahub.io/docs/working-with-accelerators
- 5: https://github.com/opendatahub-io/opendatahub-operator
- 6: https://opendatahub.io/docs/working-with-accelerators/
Correct HardwareProfile scope documentation.
Line 17 incorrectly describes HardwareProfile as "typically a cluster-scoped resource." The actual scope is namespaced, as confirmed by the CRD definition and the example YAML which includes namespace: kube-public. Update the prerequisite to reflect that users need permissions in their specific namespace, not cluster-level access.
✅ Suggested doc fix
-- You have a namespace where you have permissions to view or create `HardwareProfile` resources (typically a cluster-scoped resource or in a specific admin namespace).
+- You have permissions in the namespace where `HardwareProfile` resources are managed (for example, an admin namespace such as `kube-public`).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - You have a namespace where you have permissions to view or create `HardwareProfile` resources (typically a cluster-scoped resource or in a specific admin namespace). | |
| - You have permissions in the namespace where `HardwareProfile` resources are managed (for example, an admin namespace such as `kube-public`). |
🧰 Tools
🪛 LanguageTool
[style] ~17-~17: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...tl` to communicate with your cluster. - You have a namespace where you have permiss...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/en/infrastructure_management/hardware_profile/how_to/create_hardware_profile_cli.mdx`
at line 17, Update the prerequisite sentence that currently reads "You have a
namespace where you have permissions to view or create `HardwareProfile`
resources (typically a cluster-scoped resource or in a specific admin
namespace)" to state that `HardwareProfile` is a namespaced resource and users
must have permissions in the specific target namespace; reference the example
YAML's namespace (e.g., `namespace: kube-public`) as an example and remove the
"cluster-scoped" wording so the doc correctly requires namespace-level
permissions to view/create `HardwareProfile`.
Deploying alauda-ai with
|
| Latest commit: |
5838417
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ba41d778.alauda-ai.pages.dev |
| Branch Preview URL: | https://feat-add-hardware-profile.alauda-ai.pages.dev |
2 participants
Summary by CodeRabbit