⚠️ Clusterctlv2 add interfaces for the low-level Repository library

[fabriziopandini]

What this PR does / why we need it:
This PR adds a clusterctl interfaces low-level api for managing Repository config objects, and more specifically the interfaces for managing two types of YAML files:

• YAML files defining the provider components (CRD, Controller, RBAC etc.)
• YAML files defining the cluster templates (Cluster, Machines)

By adding those interfaces, with this PR, then it will be possible to parallelize the work of adding the concrete implementation of each interface.

Which issue(s) this PR fixes
Rif #1729

[fabriziopandini]

@ncdc @vincepri @detiber this is ready for review now

[chuckha]

My general concern here is that this is perpetuating a Go anti-pattern where the library is defining the interfaces when the consumer should be defining the interfaces.

General wisdom (and personal experience) says functions should accept interfaces and return structs. It is pretty annoying to use a library that only returns interfaces and explicitly tells me, the consumer, how i need to use the library.

I think some of these interfaces will be fine as this library will be the only thing consuming the interfaces, but the pattern of exposing the interface and having a private implementation can be quite annoying to work with.

In general, interfaces are designed by the consumer as the consumer knows how it wants to use a struct.

These blogs cover the topic fairly well

• https://peter.bourgon.org/go-for-industrial-programming/#how-much-interface-do-i-need
• https://twitter.com/davecheney/status/1030790804011245569?lang=en
• https://dave.cheney.net/2016/08/20/solid-go-design (skip down to interfaces)

If there is a good reason for this pattern can you please outline why we choose to go against general go best practices?

[fabriziopandini]

@chuckha many thanks for the detailed feedback. the articles you linked are really interesting.

I see both pros and cons approach you are proposing and in the current approach that mimics what is implemented in the Kubernetes API package; nevertheless, I will be happy to address your concerns - including also re-working of the code already merged - if the consensus goes in that direction.

Said that my major concern is to keep the clusterctl work going, so, I this will be ok for you/for the team, I would prefer to experiment on an alternative approach for the API surface in a separated PR, and use the current approach for unblocking works on the clusterctl federated repository

@ncdc @vincepri @detiber opinions?

[chuckha]

that's fine. all of kubernetes does this anyway and it's not a huge deal, it's just annoying to work with from time to time.

[vincepri]

@chuckha Are you ok to approve this PR as-is given the comments above?

We merged some other PRs that follow this pattern (or anti-pattern as you mentioned 😄). Given that the tight timeline, and that the code can always be improved in future iterations, I'd like to get these merged asap

[chuckha]

yep, it's fine to merge

[vincepri]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini, vincepri

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vincepri]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment