-
Notifications
You must be signed in to change notification settings - Fork 6
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
[operator] Readiness for Paladins and SCD Mappings #402
[operator] Readiness for Paladins and SCD Mappings #402
Conversation
Signed-off-by: hfuss <[email protected]>
Signed-off-by: hfuss <[email protected]>
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 seems like a good step forwards on all fronts, but as we've discussed it's probably not quite the end of the journey to faster deploy times.
I note we don't have service-level readiness checks on our pod defs right now, which might be good to add (although I don't know if we can make them part of the checking process for the SCD/TXInvoke paths)
StatusPhaseFailed StatusPhase = "Failed" | ||
StatusPhaseUnknown StatusPhase = "Unknown" | ||
StatusPhasePending StatusPhase = "Pending" | ||
StatusPhaseReady StatusPhase = "Ready" |
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.
Think this is a lot clearer 👍
@@ -212,12 +214,38 @@ func getContractDeploymentAddress(ctx context.Context, c client.Client, name, na | |||
|
|||
} | |||
|
|||
// TODO this is duplicated btwn here and SmartContractDeploymentReconciler, as reconcileAll alludes to, generics |
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.
We have some helpers to allow generics. Found it surprisingly hard to support them in k8s data structures, I had to introduce a thing like this to every file:
paladin/operator/internal/controller/transactioninvoke_controller.go
Lines 49 to 56 in ef6a417
// allows generic functions by giving a mapping between the types and interfaces for the CR | |
var TransactionInvokeCRMap = CRMap[corev1alpha1.TransactionInvoke, *corev1alpha1.TransactionInvoke, *corev1alpha1.TransactionInvokeList]{ | |
NewList: func() *corev1alpha1.TransactionInvokeList { return new(corev1alpha1.TransactionInvokeList) }, | |
ItemsFor: func(list *corev1alpha1.TransactionInvokeList) []corev1alpha1.TransactionInvoke { | |
return list.Items | |
}, | |
AsObject: func(item *corev1alpha1.TransactionInvoke) *corev1alpha1.TransactionInvoke { return item }, | |
} |
e2f35df
into
LF-Decentralized-Trust-labs:main
Description
Adds a readiness check to the
PaladinReconciler
based on if the underlyingStatefulSet
is ready or not, and a controller ref to allow for watching relevantStatefulSet
updates.The
SmartContractDeploymentReconciler
is then updated to only reconcile aPaladin
if the node isReady
and if the contracts refer to it.Renames the
Completed
phase toReady
, as aPaladin
can now go back toPending
if theStatefulSet
every re-reconciles due to config changes.Results
One set of enhancements which seemed to help SCD reconcile speed decently in efforts to address to #397, but contracts still get stuck even after the
Paladin
goes back toReady
after a restart, so missing a retry or a readiness check in the right place. And ideally we avoid too many pod restarts at once, but will address that in a follow up PR.I did have other contracts stuck due to encoding issues I believe will be addressed by #401.