Improve Context handling in clusterctl

[sbueringer]

What would you like to be added (User Story)?

Today we have plenty of places in clusterctl where we use context.TODO(). This issue is about incrementally improving clusterctl to pass through Context top-down.

Related:

• The recent CR bump PR (⚠️ Bump to CR v0.15.0 #8007) introduced the new wait utils from apimachinery which means it's now even easier to pass through context into code that is run inside of the wait utils.

Detailed Description

Anything else you would like to add?

No response

Label(s) to be applied

/kind cleanup
/area clusterctl

One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[sbueringer]

/triage accepted

[aniruddha2000]

Hello @sbueringer, I would like to work on this but, could you give some more context about this issue, are you talking about everywhere we use context.TODO() in clusterctl scope like this or specific to client operations? It will be helpful if you give a bit more context on this.

[sbueringer]

The scope of the issue is currently intentionally very open. I didn't do further research on which areas of clusterctl we should focus and what the impact on our public interfaces is. But yeah overall we should probably replace all occurences of context.TODO(). I would definitely recommend to open separate PRs to focus each of them on certain code paths or packages though.

@ykakarap @fabriziopandini @Jont828 Any opinions from your side?

[ykakarap]

Sounds like a good idea. I would recommend starting with some simple wins like evaluating any root level context that are being using and seeing if we can replace them with the right context (context.Background (?) or whatever is reelvant).

Refactoring some of the other code to pass through context from top-down might get a little tricky and we should evaluate them on a case by case basis as refactoring some of these functions would mean some of the exported clusterctl interfaces would be impacted.

[ykakarap]

Given our current clusterctl compatibility guarantee it is technically okay for us to make the changes to the interface but it would be a nice to have if we can find a way to keep the impact small.

[Fedosin]

Since we use a lot of clusterctl functions in Cluster API operator, it would be beneficial for us to support "context" here. I'm going to implement a fix later today to instrument all required functions with "context".