Add Hardware resources and BMCRef #614
Conversation
Codecov Report
@@ Coverage Diff @@
## main #614 +/- ##
=======================================
Coverage 44.65% 44.65%
=======================================
Files 61 61
Lines 3509 3509
=======================================
Hits 1567 1567
Misses 1860 1860
Partials 82 82
Continue to review full report at Codecov.
|
micahhausler
force-pushed
the
hardware/resources
branch
2 times, most recently
from
41c6afe
to
d2365b8
Compare
micahhausler
force-pushed
the
hardware/resources
branch
from
d2365b8
to
105c9df
Compare
| resources: | ||
| additionalProperties: | ||
| anyOf: | ||
| - type: integer |
There was a problem hiding this comment.
Do we need clarification in the description on the assumed unit when specifying as an integer?
There was a problem hiding this comment.
In-fact I don't think that makes sense because describing a CPUs is a single number. Something still seems odd though, how are users meant to know what value to use?
There was a problem hiding this comment.
I don't think so, its a Kubernetes type which has its own documentation
There was a problem hiding this comment.
CPUs can be fractional for K8s pods, or whole numbers. See the Format godoc example
There was a problem hiding this comment.
Right, but fractionality doesn't make sense in Tinkerbell. We only talk in terms of whole CPUs hence I'm wondering if we need to better define boundaries seeming as we're leveraging an existing type with behavior beyond our need.
I'd hate to see someone define a Hardware with .5m CPU for example and it seems like this is open to that sort of accidental usage.
There was a problem hiding this comment.
To clarify, I agree this doesn't need additional documentation from my OP about units assumed with integers. I've shifted to "are our bounds adequately described" because the resource.Quantity supports stuff beyond what we want.
Signed-off-by: Micah Hausler <mhausler@amazon.com>
micahhausler
force-pushed
the
hardware/resources
branch
from
105c9df
to
30fe9e0
Compare
I'm a maintainer of several other services often related to the Kuberenetes back-end/Kubernetes controllers and I'm taking ownership for a lot of release synchronization making it both appropriate and necessary for me to maintain aspects of the Tink repository. Requirements: - I have reviewed the [community membership guidelines](https://github.com/tinkerbell/proposals/blob/main/proposals/0024/GOVERNANCE.md) - I have [enabled 2FA on my GitHub account](https://github.com/settings/security) - I have subscribed to the [tinkerbell-contributors e-mail list](https://groups.google.com/g/tinkerbell-contributors) - I am actively contributing to 1 or more Tinkerbell subprojects Here is a list of non-trival PRs I have been the primary reviewer on: #596 #628 #614 I have also made a number of code contributions to this repository, here are a few of them: #638 #631 #626 #622 #612 I have also raised various issues and am driving the releasing across Tinkerbell including in this repository. Requesting consideration of expedited responsibilities: yes Sponsors: - @mmlb (Maintainer) - @micahhausler (Maintainer) - @jacobweinstock (Core contributor in other Tinkerbell repositories)
Signed-off-by: Micah Hausler mhausler@amazon.com
Description
This PR adds two fields for external orchestrators (such as CAPT) to
How Has This Been Tested?
N/A. No
How are existing users impacted? What migration steps/scripts do we need?
No change to existing users.
Checklist:
I have: