-
Notifications
You must be signed in to change notification settings - Fork 137
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
v1alpha2 Workflow Controller #874
Conversation
d927835
to
eb5eb09
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #874 +/- ##
==========================================
- Coverage 51.23% 50.61% -0.63%
==========================================
Files 33 36 +3
Lines 1458 1549 +91
==========================================
+ Hits 747 784 +37
- Misses 665 712 +47
- Partials 46 53 +7 ☔ View full report in Codecov by Sentry. |
c0c4a06
to
f22864f
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.
Thanks for the work on this, @chrisdoherty4. Left some comments for discussion.
@@ -49,21 +49,21 @@ help: ## Print this help | |||
VERSION ?= $(shell git rev-parse --short HEAD) | |||
|
|||
# Define all the binaries we build for this project that get packaged into containers. | |||
BINARIES := tink-server tink-agent tink-worker tink-controller virtual-worker | |||
BINARIES := tink-server tink-agent tink-worker tink-controller tink-controller-v1alpha2 virtual-worker |
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.
not too excited we have to use tink-controller-v1alpha2
:(
@@ -30,7 +30,7 @@ type Condition struct { | |||
Status ConditionStatus `json:"status"` | |||
|
|||
// LastTransition is the last time the condition transitioned from one status to another. | |||
LastTransition *metav1.Time `json:"lastTransitionTime"` | |||
LastTransition metav1.Time `json:"lastTransitionTime"` |
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.
I know you love pointers ;) so why move away from one here?
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 isn't optional because we expect the LastTransition to be updated even if we're populating the first status.
@@ -0,0 +1,179 @@ | |||
package main |
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.
is v1alpha2 so different from a cmd/cli perspective that we have to break it out entirely? Could a flag be used in the existing tink-controller?
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.
I'm open to using a single binary. This temporary extra binary just felt simpler to me. There won't be a transition period where both APIs are supported so eventually tink-controller-v1alpha2
will become tink-controller
.
@@ -0,0 +1,10 @@ | |||
FROM alpine:3.15 |
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.
any reason not to use scratch
?
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.
I don't know. The goal of the PR is to get something functional so I've not experimented.
v := viper.New() | ||
v.AutomaticEnv() | ||
v.SetConfigName("tink-controller") | ||
v.AddConfigPath("/etc/tinkerbell") |
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.
do we need a default location for a config file? does this provide much value, you think?
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.
Probably not; this is copy-n-paste from the existing tink-controller. If we maintain the temporary v1alpha2 binary, I'll reduce this down to bare minimum so we don't end up with cruft down the road.
@@ -0,0 +1,135 @@ | |||
package internal_test |
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.
im not fond of internal_test
files that use dot notation import for the package it's testing. I don't see the value. Not anything to hold up the PR, just wanted to voice it. : )
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.
Do you mean specifically for internal
packages, or do you mean generally the _test
idiom with dot import?
Either way, dot imports are just a convenience thing, and this is the only acceptable usage.
|
||
func (r *Reconciler) Reconcile(ctx context.Context, req reconcile.Request) (reconcile.Result, error) { | ||
func (r *Reconciler) Reconcile(ctx context.Context, req reconcile.Request) (result reconcile.Result, rerr error) { |
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.
are we gaining any value by having named return values? I don't see them being used, feels unnecessary.
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.
The named returns are included for the defer to work because we change the return variable if patching fails. I don't think the code needs to work this way, and honestly I'm not fond of the defer approach - defering the patch is a common method for always patching.
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.
oh its the rerr
that is used not result
. But obviously we cant just have a single named return. i see now.
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.
Well, that's a good point: _
.
// Mark the workflow as timed out | ||
stored.Status.State = v1alpha1.WorkflowStateTimeout | ||
} | ||
// Always attempt to patch. |
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.
Why always attempt a patch?
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.
The rationale is that you do as much as possible to bring the resource to the desired state and you shouldn't update the .Status
state if nothing changed so always patching ensures we always try to persist the updates.
Hey @chrisdoherty4 , feel free to merge as is. We can address these before the official removal of v1alpha1. |
f22864f
to
cf8692a
Compare
Signed-off-by: Chris Doherty <[email protected]>
Signed-off-by: Chris Doherty <[email protected]>
cf8692a
to
8a89f80
Compare
Introduce basic functionality for a v1alpha2 Workflow Controller. This implementation is independent of the existing controller as we won't support the v1alpha1 API when we move to v1alpha2. The first commit moves deprecated code into /internal/deprecated and isn't that interesting: the work is mostly in the second commit.
The implementation renders the template actions onto the Workflow only which will aid in E2E tests with Tink Server. Logic such as remediating Workflow states is deferred to a later PR.