Generalize the hardware client interface #81
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chrisdoherty4
force-pushed
the
cpd/generalize-hardware-client
branch
from
0b2c350 to
5cd325b
Compare
Codecov Report
@@ Coverage Diff @@
## main #81 +/- ##
==========================================
+ Coverage 50.71% 50.83% +0.12%
==========================================
Files 3 3
Lines 418 417 -1
==========================================
Hits 212 212
+ Misses 175 174 -1
Partials 31 31
Continue to review full report at Codecov.
|
thebsdbox
previously approved these changes
Apr 7, 2022
mmlb
suggested changes
Apr 7, 2022
chrisdoherty4
force-pushed
the
cpd/generalize-hardware-client
branch
from
5cd325b to
001aff6
Compare
mmlb
previously approved these changes
Apr 7, 2022
The hardware client is used to interact with a Cacher service and the Tink service. It embodies gRPC specific types and an ambiguous All() call that are difficult to model for a Kubernetes data provider. This change alters the interface to model more generic behavior and removes gRPC specific types paving the path for implementing a Kubernetes data provider client. Signed-off-by: Chris Doherty <[email protected]>
chrisdoherty4
force-pushed
the
cpd/generalize-hardware-client
branch
from
001aff6 to
06a4519
Compare
mmlb
approved these changes
Apr 8, 2022
mergify bot
added a commit
that referenced
this pull request
May 9, 2022
## Description Builds on #95 (rebased after PR was created) This feature builds on #81 and realizes the Hegel portion of the [Kubernetes back-end proposal](https://github.com/tinkerbell/proposals/tree/main/proposals/0026). Having generalized the client used to acquire metadata, this PR implements a Kubernetes client that leverages an internal client caching mechanism so as to reduce load on the Kubernetes API Server. Additionally, I put some effort into reworking the Hegel Dockerfile so it could leverage layer caching for Go module dependencies and added an image build command to the Makefile. The `Watch` API for the client is unimplemented and scheduled for a follow up. This is so we can get off the ground for machine provisioning. The `Watch` API is used for subscription capabilities so doesn't feature in metadata retrieval. ## How Has This Been Tested? Built and ran the image with the Kubernetes back-end enabled talking to a KinD cluster containing the necessary CRDs and a `Hardware` resource. ## How are existing users impacted? What migration steps/scripts do we need? None. Users enable the Kubernetes back-end by setting the `DATA_MODEL_VERSION=kubernetes` plus some additional env vars. ## Future work - Implement the `Watch` API for consistency with other back-ends.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
To compliment the Kubeification of Tinkerbell's back-end we need to provide a mechanism for supplying hardware data from the Kubernetes API Server in Hegel.
Changes
The hardware client is used to interact with a Cacher service and the Tink service. It embodies gRPC specific types and an ambiguous All() call that are difficult to model for a Kubernetes data provider.
This change alters the interface to model more generic behavior and removes gRPC specific types paving the path for implementing a Kubernetes data provider client that can plug into existing business logic.
This change doesn't alter any service behavior.