-
Notifications
You must be signed in to change notification settings - Fork 220
Consider a simpler Matcher
interface
#986
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
Comments
The match is quite a generic problem. Or a problem that could be solved in a very generic way, based on desire and the actual state (what we already do in the current implementation). Hopefully most of the users will be just use the default implementation out of the box. I absolutely agree that some might need the primary to optimize for some special cases. On the other hand removing the desired would mean in generic implementation, that we would need to compute it there, and if not matches compute it again on update. So IMHO would do just a compromise between. Adding the primary but not removing the desired from the interface. Creating desired is just a POJO mapping basically from primary to desired, what is an extremely fast and non resource intensive operation, not sure if optimizing that makes sense in this case. |
The default implementation is not neutral, though, at least for Kubernetes resources: it serialises both desired and actual resources then performs a JSON diff, which can potentially be rather intensive for large or often changing resources.
The generic implementation is only used for Kubernetes dependents where, usually, computing the desired state is less resource-intensive than the actual comparison. That said, with some changes to the Matcher interface we could avoid this issue altogether.
It's not always true, though, if the desired state is complex to compute or if it deals with external resources |
Yes, we should measure this part, to see the actual numbers.
Not sure I understand what you mean here. For non kubernetes like MySQL Schema, usually equals is used so, |
Right now, the
Matcher
interface defines a single method:public boolean match(Deployment actual, Deployment desired, Context context)
. This works quite nicely for the default implementation. However, in many cases, when people actually want to implement their own optimised version, it would be more effective and efficient to get the primary resource instead of the desired state as the desired state might be quite complex (e.g. aDeployment
) and navigating to the salient parts, not easy.Contrast the following implementations:
I think the second implementation is clearer as to what is going on exactly and the relation to the primary resource state clearer. Granted, in this second case, we do need to convert part of the actual state to something that matches what is provided by the primary resource (that's the purpose of the
convert
method) but the relation between the primary resource state and whether the dependent state matches it is more explicit in this case.This would also have the added benefit of not having to compute the full desired state if we can determine quickly that the actual state matches the expectations set by the primary resource as
AbstractDependentResource.reconcile
could be rewritten as follows:The text was updated successfully, but these errors were encountered: