Skip to content
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

[WIP] 📖 Add docs for writing provider integrations #30

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

janiskemper
Copy link
Member

What this PR does / why we need it:
Adding docs for writing provider integrations

Which issue(s) this PR fixes:
Fixes #29

TODOs:

  • squash commits
  • include documentation
  • add unit tests

Adding docs for writing provider integrations

Signed-off-by: janiskemper <[email protected]>
@jschoone jschoone added the Container Issues or pull requests relevant for Team 2: Container Infra and Tooling label Nov 15, 2023
Copy link

@NotTheEvilOne NotTheEvilOne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept in mind that the state is WIP, so this "review" is more of a reminder of the current state where most details should be added in the ongoing process. I haven't commented on the most important but empty section "Implementing a new Provider Integration" in this review.

docs/PROVIDER.md Show resolved Hide resolved
docs/PROVIDER.md Show resolved Hide resolved
docs/PROVIDER.md Outdated

In case that there are multiple node images which have to be provided to the user, it makes sense to have separate custom resources so that one custom resource is responsible for only one node image. A pattern where there is a `ProviderClusterStackRelease` that creates different `ProviderNodeImageRelease` custom resources, one for each node image that should be built, is advisable.

The same pattern that is also used in the objects of `ClusterStackRelease` and `ProviderClusterStackRelease` can be also applied here in a way that `ProviderClusterStackRelease` is set on `ready: true` if and only if all `ProviderNodeImageRelease` custom resources are also `ready: true`.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here as before. As long as there is no common structure for ProviderNodeImageRelease specs will most likely differ fundamentally resulting in bad readability on provider's code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree here. Why should that be the case? Reliability of code will be mostly about how people write their code, not about how they name their API. And we cannot control how they write the code anyway.
Maybe I misunderstand also what you mean, so you can elaborate maybe?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's about using Go's rudimentary support for interfaces to enforce / provide a certain structure for resources expected to be handled the same way for each provider implementation anyway not how the result is achieved using provider specific code that will be fundamentally different.

Take a look at CSI drivers as an example. They all implement common interfaces and work with storage classes. Commonly under parameters the filesystem type was and sometimes is defined as fstype. This meant that is was not always named the same way and moving from cloud to cloud got complicated. These days the external-provisioner handles PVC requests and storage classes. They provided the common name [1] csi.storage.k8s.io/fstype to handle the filesystem type the same way for all CSI drivers [2] and the common interface they share (it's used in e.g. NodeStageVolume under req.VolumeCapability).

[1] https://kubernetes-csi.github.io/docs/external-provisioner.html#storageclass-parameters
[2] https://github.com/kubernetes-csi/external-provisioner/blob/b255ee8f41384b330388c00a5f9252aff343fecf/pkg/controller/controller.go#L612

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We evaluated an interface approach, taking the Cloud Controller Manager as example. However, this is unfortunately not possible, same as with CAPI Provider Integrations, as provider-specific CRDs are needed!

janiskemper pushed a commit that referenced this pull request Nov 28, 2023
Copy link
Member

@matofeder matofeder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, LGTM, just a few minor suggestions

docs/PROVIDER.md Show resolved Hide resolved
docs/PROVIDER.md Show resolved Hide resolved
## Implementing a new Provider Integration

// TODO This has to be refined based on https://cluster-api.sigs.k8s.io/developer/providers/implementers-guide/overview.
// The goal is that users can set up new repositories by themselves and know everything that is needed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that this part will be the most important, so I would recommend addressing it before we merge this PR.

@janiskemper
Copy link
Member Author

@michal-gubricky @NotTheEvilOne @jschoone I have added the documentation that we talked about in yesterday's meeting. I updated the previous section about best practices to make it clearer. @michal-gubricky if there are some open questions to you that I haven't answered yet, please tell me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Container Issues or pull requests relevant for Team 2: Container Infra and Tooling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Documentation how to write Cluster Stack Provider Integrations
4 participants