-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add running workflow for worker index to cache #599
Conversation
b42a5c2
to
58a3754
Compare
Codecov Report
@@ Coverage Diff @@
## main #599 +/- ##
==========================================
- Coverage 45.94% 45.68% -0.27%
==========================================
Files 53 55 +2
Lines 3182 3301 +119
==========================================
+ Hits 1462 1508 +46
- Misses 1634 1707 +73
Partials 86 86
Continue to review full report at Codecov.
|
58a3754
to
26dcb89
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good and is consistent with our existing index.
I have some questions about the format of keys (should they start with a .
), names of meta keys (is the snake case field name conventional), and return values (Indexer documentation says only return a single string for Kubernetes compatibility), but our existing index brings up the same questions. (I wont hold this up on that)
I'm happy to prefix with a period
Good catch, I'll fix this to be more inline with the API field name convention
I believe this only matters if you wanted to compatibility with a field-selector in the API, which we don't here. We intentionally want all the workers for a particular workflow. |
26dcb89
to
1e2fb3f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of questions on the index itself, but I'm curious why this is part of pkg/controllers/manager.go
if it's expected to be consumed by boots or other clients, would it make more sense to have it in a separate package to be consumed by the clients?
pkg/controllers/manager.go
Outdated
@@ -17,7 +17,8 @@ import ( | |||
) | |||
|
|||
const ( | |||
WorkerAddr = "status.tasks.workeraddr" | |||
WorkerAddrIndex = ".status.tasks.workerAddr" | |||
NonTerminalStateIndex = ".status.state.nonTerminalWorker" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious to see if it would make sense to break this out on a per-state basis instead of just non-terminal states.
I'm also wondering if we might run into issues based on the field naming here, given the comment about the FieldIndexer
interface here: https://pkg.go.dev/sigs.k8s.io/[email protected]/pkg/client#FieldIndexer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious to see if it would make sense to break this out on a per-state basis instead of just non-terminal states
I've added an additional index for state, WorkflowStateIndex
and I've updated the index variable names for clarity. Take a look at the documented example under FieldIndexer
, the Index name is just a key to lookup an object based on shared understanding of what that index means. In the documented example, the field name is spec.volumes.secret.secretName
and returns all the secret names mounted on a pod.
Is there anywhere else you're thinking of specifically? This code is importable by Boots in the current package. Boots will become just a client of Kubernetes, as opposed to the Tinkerbell API. In that architecture, Boots will need still need indexes on Hardware by MAC and IP, as well as workflows for a particular worker. |
a40de6e
to
13455f4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks OK to me, based upon reading through the code and a review of the comments. Unless @detiber has any strong feelings on the convo re:boots.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm after the func comment is fixed
13455f4
to
90101b6
Compare
After taking a look at #600, does it make more sense to get that merged first and then use the defined constants instead of bare strings here? |
* Add tests on index functions * Add constants for action states Signed-off-by: Micah Hausler <[email protected]>
90101b6
to
eb40dae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
Description
Adds indexer so clients can query for running workflows by a particular worker address
Signed-off-by: Micah Hausler [email protected]
Why is this needed
Boots needs to import this logic and query for these workflows
Fixes: # N/A
How Has This Been Tested?
Added unit tests for existing and new index functions
How are existing users impacted? What migration steps/scripts do we need?
N/A
Checklist:
I have: