Cluster-api: docs/book: Update CAPD quickstart once ships in this repository

[vincepri]

/kind documentation
/milestone v0.3.0
/priority important-longterm
/help

[k8s-ci-robot]

@vincepri:
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:

/kind documentation
/milestone v0.3.0
/priority important-longterm
/help

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.

[ncdc]

We also need to adjust the Makefile to include the docker-infrastructure-components.yaml (or whatever we call it) in each CAPI release, right?

[vincepri]

IIRC we mentioned that CAPD might go in separate releases, given that's also a separate go module

[chuckha]

Do you think CAPD still has a place in the quickstart? It's helpful for testing but I'm not sure it's something we necessarily need to ship. This is a loosely held opinion. I don't feel very strongly about this. Basically I'm interested in supporting fewer things for users. Either way though I expect we'll be supporting CAPD for the e2e framework.

[chuckha]

cc @dlipovetsky since he added the capd quickstart guide

[ncdc]

+1 to removing it from the quickstart

[dlipovetsky]

Thanks for /cc'ing me @chuckha !

In my view, CAPD provides CAPI consumers (in additiona CAPI developers) a fast, low-cost way of evaluating and experimenting with the CAPI model. I believe that this, in turn, helps CAPI adoption.

I worry that CAPI consumers not be able to easily discover and use CAPD if we remove it completely from the general quick-start.

Basically I'm interested in supporting fewer things for users.

Are you concerned about breaking changes? If so, would it help to make it more clear in the quick start that CAPD is meant for experiments and short-lived clusters?

[chuckha]

Are you concerned about breaking changes? If so, would it help to make it more clear in the quick start that CAPD is meant for experiments and short-lived clusters?

I'm concerned about having too large of a support surface area and not enough people to continue to pull everything forward while still making progress on the core and keeping the core code stable and solid, but if fixing this issue isn't a big deal then I don't mind keeping it.

I worry that CAPI consumers not be able to easily discover and use CAPD if we remove it completely from the general quick-start.

Developers will hopefully stumble upon it as it is enabled by default in the Tiltfile.

One other thing we could add a page to the Developer Guide and write a bit about running CAPD from master so that we don't have to release images and manifests with CAPI.

[ncdc]

From today's meeting: it's nice to keep the examples. Can debate location of docs over time.

[ncdc]

@dlipovetsky how would you feel about this?

• We move all references to CAPD so they're only in the Developer Guide, possibly in the Tilt docs, or possibly as a standalone topic
• We remove the docker provider from the clusterctl code base, and require that you set up the local overrides if you want to use it (you'd also have to use kustomize to generate the yaml)

[dlipovetsky]

Thanks for asking!

We move all references to CAPD so they're only in the Developer Guide, possibly in the Tilt docs, or possibly as a standalone topic

No objections. But I would like to leave a note about CAPD in the quick start that contains a link to the separate doc.

We remove the docker provider from the clusterctl code base, and require that you set up the local overrides if you want to use it (you'd also have to use kustomize to generate the yaml)

Forgive me, but I don't know the motivation for this. In general, I think CAPD should be as easy to use as any other provider.

[vincepri]

Forgive me, but I don't know the motivation for this. In general, I think CAPD should be as easy to use as any other provider.

You can still use it, and we'll provide some automation around it for developers. The main issue having CAPD in clusterctl is that there won't be published artifacts, in the form of a github release. When I chatted with @fabriziopandini we thought it'd make sense to document now the necessary steps to use CAPD with clusterctl in the book, and rework the development experience in a patch release

[dlipovetsky]

You can still use it, and we'll provide some automation around it for developers.

But it won't be as easy to use CAPD as other providers.

The main issue having CAPD in clusterctl is that there won't be published artifacts, in the form of a github release.

Can I help with this, or anything else that allows us to keep CAPD a "first-class" provider?

[fabriziopandini]

@dlipovetsky all the clusterctl provider management assumes there are published artifacts for a provider.

the documentation mostly describes how to build the artifact for CAPD.
once artifacts are in place, and clusterctl is configured to access such artifacts, the clusterctl steps are the same of other providers

[ncdc]

Can I help with this, or anything else that allows us to keep CAPD a "first-class" provider?

@dlipovetsky would you be willing to help maintain CAPD, including getting the various Makefiles into shape to get the bits published?

[dlipovetsky]

@dlipovetsky would you be willing to help maintain CAPD, including getting the various Makefiles into shape to get the bits published?

Yes!

[dlipovetsky]

I talked to @vincepri offline.

1. There's no way to release CAPD today (in short, CAPD is a go submodule, our prow jobs are not currently set up to work with a go submodule)
2. Official CAPD release might signal that it's acceptable for uses other than testing
3. No one available to maintain a separate CAPD release, e.g. patching, back-porting

Because of (1), we will not be able to release CAPD v0.3 next week. If there's no official CAPD release, it's a good idea to move CAPD out of quick start.

I still believe it's valuable to make CAPD easy to use for non-developers. I'll work with @vincepri and @fabriziopandini to find some solution that doesn't require an official CAPD release, e.g., making CAPD a clusterctl "built-in."

[vincepri]

/milestone v0.3.x

Moving from being release-blocking

[vincepri]

Should we close this issue now that we have https://cluster-api.sigs.k8s.io/clusterctl/developers.html#additional-steps-in-order-to-use-the-docker-provider? @fabriziopandini @dlipovetsky

[vincepri]

/close

closing due to timeout

[k8s-ci-robot]

@vincepri: Closing this issue.

In response to this:

/close

closing due to timeout

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.