Add helm chart

[stevehipwell]

Description

Adds a Helm chart based on the official manifests in the repo; the Helm repo will be hosted by GitHub pages at https://kubernetes-sigs.github.io/external-dns/.

Adds required GitHub Actions CI.

• A PR making changes to files in /charts/external-dns/** will trigger the lint and test action
  • If the chart has changed then the chart version should be updated accordingly or else the CI will error
• If changes are made to files in /charts/external-dns/** on the master branch a release will be made
  • The gh-pages branch needs to be setup so the release action can use it as the Helm repo

The chart is fully documented but I've not linked it in to any of the other documentation as maybe this should be a soft launch? Otherwise could someone point me in the right direction to put the documentation in the correct place.

Fixes #1941

Checklist

• Unit tests updated
• End user documentation updated

[k8s-ci-robot]

Welcome @stevehipwell!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. 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/external-dns 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. 😃

[stevehipwell]

/assign @Raffo

[dirien]

Hi,

Left some comments.

[njuettner]

Seems like the linter is failing 😞

Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning  FailedScheduling  33s (x5 over 5m1s)  default-scheduler  0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.

[stevehipwell]

@njuettner the Kind action failed (see helm/kind-action#41 for why it didn't error) which causes later actions to fail. If you have the permissions could you re-run the action?

Creating cluster "chart-testing" ...
• Ensuring node image (kindest/node:v1.19.1) 🖼 ...
✓ Ensuring node image (kindest/node:v1.19.1) 🖼
• Preparing nodes 📦 ...
✓ Preparing nodes 📦
• Writing configuration 📜 ...
✓ Writing configuration 📜
• Starting control-plane 🕹️ ...
✓ Starting control-plane 🕹️
• Installing CNI 🔌 ...
✓ Installing CNI 🔌
• Installing StorageClass 💾 ...
✓ Installing StorageClass 💾
• Waiting ≤ 1m0s for control-plane = Ready ⏳ ...
✗ Waiting ≤ 1m0s for control-plane = Ready ⏳
• WARNING: Timed out waiting for Ready ⚠️

[stevehipwell]

@Raffo could you re-run the lint-test action for the above mentioned reason?

[stevehipwell]

@Raffo @njuettner I've pushed again so it looks like the actions will need to be enabled again.

[Raffo]

@stevehipwell I enabled CI, the linter is still unhappy.

[stevehipwell]

@Raffo I can't get to the logs but was the Kind cluster creation good or did that never get healthy?

[stevehipwell]

I got to the logs, it looks like it was Kind. Could you re run the action?

[Raffo]

@stevehipwell kind being unkind uh 😅 rerunning!

[Raffo]

And it failed again. I think the build deserves a deeper look on why this is happening.

[jordiprats]

Hi guys,
I'm hoping this would merged so I took a look, it says:

https://github.com/kubernetes-sigs/external-dns/pull/2208/checks?check_run_id=3320498211

0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate

I'm not familiar with the cluster were you are running this but sounds like it is spawning a new node to run this pod and you are not waiting long enough for the node to become ready.

[stevehipwell]

If I remember correctly it's possible to increase the timeout on the Kind action. I run a number of charts with this exact config and up until recently hadn't seen this issue; up until this point I think I've only ever seen it twice in well over 50 runs.

[k0da]

@stevehipwell you can use act to simulate GHA runs locally. Also we found k3d project is more lightweight to spawn k8s clusters for CI. Here is the action for k3d. JFYI

[stevehipwell]

Thanks @k0da, as I said above this pattern has been working for years and hundreds of chart PRs so I've no idea why it's suddenly got brittle.

[stevehipwell]

@Raffo I've updated the Kind action version (I thought I'd already done this) and added a longer wait for the cluster to be ready which should solve this.

[Raffo]

@stevehipwell CI is green and the chart content looks all right to me. However, I think that we need to remove/change the part on releasing the chart: we have a consolidated release process described in https://github.com/kubernetes-sigs/external-dns/blob/master/docs/release.md and we would need to make creating the release part of it. I also would love to avoid having multiple github releases for what are code and helm changes. Would you be able to propose a change to incorporate that?

[stevehipwell]

@Raffo unfortunately the chart releaser will create a GitHub release for each chart release and there is no way to change this behaviour. You'll see in the release action that the suffix -helm-chart is added to distinguish the release.

Would it be easier to merge this PR and add the documentation separately as the first release only requires the gh-pages branch to be created with GitHub pages enabled and the PR to be accepted?

[onedr0p]

@stevehipwell would it be beneficial to include the external-dns DNSEndpoint CRD in a crds folder? See the this chart for an example. Otherwise I am not seeing how to install the DNSEndpoint CRD besides k apply -f docs/contributing/crd-source/crd-manifest.yaml

It appears like bitnami includes the CRD in their helm chart. However they are doing it wrong IMO, it should not be templated.

According to the helm docs:

With the arrival of Helm 3, we removed the old crd-install hooks for a more simple methodology. There is now a special directory called crds that you can create in your chart to hold your CRDs. These CRDs are not templated, but will be installed by default when running a helm install for the chart. If the CRD already exists, it will be skipped with a warning. If you wish to skip the CRD installation step, you can pass the --skip-crds flag.

[stevehipwell]

@onedr0p if the CRDs are fully supported then they should be in the CRDs chart folder, but as they're not in the standard manifest install I've not added them.

However if you read the Helm 3 docs you will see that although CRD support is partially implemented you shouldn't use it and disable installing CRDs with the --skip-crds flag then manage your CRDs with kubectl.

[Raffo]

Would it be easier to merge this PR and add the documentation separately as the first release only requires the gh-pages branch to be created with GitHub pages enabled and the PR to be accepted?

This sounds good to me.

[Raffo]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: njuettner, Raffo, stevehipwell

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 [Raffo,njuettner]

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

[stevehipwell]

@Raffo @njuettner would either of you be willing to sponsor me as a member of the Kubernetes SIGs GitHub organisation?

[Raffo]

@stevehipwell what would be the need? Approving the Helm chat prs?

[stevehipwell]

@Raffo being in the owners file to get notified of chart PRs to review would be the main reason. I maintain multiple Kubernetes SIGs charts so it'd be easier if I was a member.