Machine filters (controlplane/kubeadm/internal/macine_filters) do not return any errors hence adding a logger to this package will give some visibility into if/when an error occurs.
/help
/priority backlog
cc @detiber
@sedefsavas:
This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
Machine filters (controlplane/kubeadm/internal/macine_filters) do not return any errors hence adding a logger to this package will give some visibility into if/when an error occurs.
/help
/priority backlogcc @detiber
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/milestone v0.3.x
I'm debated on this one.
I think we are pushing too much application logic into machine filters, also code that Gets data from K8s.
So IMO a better approach to solving this problem is to have a unique method that collects all the required info upfront, with proper error management, and to use filters only ... as a filter.
I agree with @fabriziopandini, the filters should just be doing filtering, so they should only take values that have sufficient information for doing the filtering, not stuff like client.Client.
Another way of thinking about this is is that filters should be pure functions
/close
@vincepri: Closing this issue.
In response to this:
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
This is not necessary after the refactor in https://github.com/kubernetes-sigs/cluster-api/pull/3405/files that moved the code that can generate errors to the NewControlPlane func