🌱 Remove nested provider from book

[taladar]

The nested provider repository is archived and the current version of clusterctl is not compatible with it anymore (v1beta1 vs. v1alpha4) so it should not be in the provider list in the book.

[linux-foundation-easycla]

• ❌ - login: @taladar / name: Matthias Hörmann . The commit (c9e920b) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign fabriziopandini for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[k8s-ci-robot]

This PR is currently missing an area label, which is used to identify the modified component when generating release notes.

Area labels can be added by org members by writing /area ${COMPONENT} in a comment

Please see the labels list for possible areas.

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-sigs/prow repository.

[k8s-ci-robot]

Welcome @taladar!

It looks like this is your first PR to kubernetes-sigs/cluster-api 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/cluster-api has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @taladar. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[taladar]

Just so you know, I am not going to read multiple pages and sign a CLA for a PR that literally removes two lines from some documentation. Feel free to merge it anyway or close it if that is an insurmountable obstacle for your legal processes.

[sbueringer]

cc @fabriziopandini

[fabriziopandini]

FYI, last time we discussed this topic we decided to keep in the book also providers not mantained anymore, because they can still provide value to the community.

The book on main has been already updated accordingly https://main.cluster-api.sigs.k8s.io/reference/providers

[taladar]

In that link I see no indication that the providers are unmaintained, the downside is that I wasted time trying to get a provider working that is clearly not usable anymore because clusterctl literally refuses to use it.

[fabriziopandini]

We tried to address this with:

Each provider is the responsibility of the respective maintainers and we highly recommend everyone interested in a specific provider to engage with the corresponding team to show support, share use cases, learn more about the other users of the same provider.

We also recommend to read provider’s documentation carefully, test it, and perform a proper due diligence before deciding to use a provider in production, like you will do for any other open source project.

Feel free to propose improvements to this statement if this is not clear enough.

[taladar]

Maybe providers that are just there for historical reasons and are known not to work with the current version could be moved to their own section at the end since they are really only relevant to people who might want to revive the project?

[fabriziopandini]

Maybe providers that are just there for historical reasons and are known not to work with the current version could be moved to their own section at the end since they are really only relevant to people who might want to revive the project?

We discussed this option, but we did not want to/we don't have bandwidth to check all the providers periodically, and we considered not fair to take a stance only for a subset of providers (and without an agreed definition of what is un-mantained or mantained or what works and what not).