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

Write docs for authoring providers #104

Open
camertron opened this issue Jul 21, 2022 · 0 comments
Open

Write docs for authoring providers #104

camertron opened this issue Jul 21, 2022 · 0 comments

Comments

@camertron
Copy link
Member

camertron commented Jul 21, 2022

The documentation site (getkuby.io) currently doesn't contain any documentation for writing providers. While providers are very much like plugins, they have a slightly different interface that should be documented. For those looking to write a provider, the interface is defined here. The only methods subclasses are required to define are kubeconfig_path and storage_class_name, which are described in further detail below.

  • kubeconfig_path. Returns a string containing the path to the kubeconfig file used to communicate with the Kubernetes cluster. Most hosting providers like DigitalOcean, Linode, etc, feature an API that can be used to fetch a copy of the kubeconfig that can be used by kubectl (what Kuby uses under the hood) to communicate with the cluster.
  • storage_class_name. Returns a string that corresponds to the storage class the provider uses for persistent volumes. For example, DigitalOcean's storage class is "do-block-storage". Consult the provider's documentation for the right storage class to use. When in doubt, try "default" (which should probably just be the default if you don't provide one, I'll work on that).

Until I have a chance to write up some real documentation, enterprising plugin authors can also consult the implementations of the existing provider gems:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant