helm chart: v4 refactor

[joshuabaird]

This PR implements several re-factors for the initial Helm chart v4 release of fluent-operator:

• Include fluent-bit and fluentd CRDs in the crds/ directory of the fluent-operator chart to follow Helmv3 standards and best practices
• Adds a new fluent-operator-crds chart that enables optional advanced/out-of-band management of the fluentd and fluent-bit CRDs
• Remove legacy CRD chart dependencies from the fluent-operator chart
• Remove legacy (also unreleased!) fluent-bit-crds and fluentd-crds charts (no longer necessary since we introduced the fluent-operator-crds chart)
• Reformat fluent-operator's values.yaml to be compatible with helm-docs so we can autogenerate docs for the chart
• Moves our "non-standard" README content to _docs.md so it gets picked up by templating already in place over in fluent/helm-charts
• Updates v4 MIGRATION doc

[stevehipwell]

@joshuabaird this looks like a better pattern, I've added a couple of nits that may be useful.

RE the bigger picture, I think the following are worth considering.

• Don't keep the README in this repo
  • Keep the README template in the helm-charts repos and generate the README as part of the PR to copy the chart there
  • This will make it clearer that the chart in this repo shouldn't be used
• Don't Update Chart.yaml version in this repo
  • Keep version static (e.g. 0.0.1-dev.0)
  • Update appVersion as appropriate
  • Set the version in the PR to copy the chart to the helm-charts repo
  • This will make it clearer that the chart in this repo shouldn't be used

[joshuabaird]

@cw-Guo @marcofranssen Could use some help reviewing and testing this if you have some time, please!

[stevehipwell]

LGTM

[cw-Guo]

Hi @joshuabaird i have a few questions as below:

1. Just to clarify the goal: are we aiming to provide two separate Helm charts—one for a minimal/vanilla install, and another for a "read-to-use" install with common logging configurations pre-enabled?
2. Could we reconsider the naming to better differentiate the fluent-operator and fluent-operator-crd charts? The current naming might confuse users into thinking the standard fluent-operator chart doesn't include CRDs, and don't know which one to use.
3. For the fluent-operator-crd chart, should it also include the deployment of the operator itself, or is it strictly for the CRDs?

[joshuabaird]

Hi @joshuabaird i have a few questions as below:

1. Just to clarify the goal: are we aiming to provide two separate Helm charts—one for a minimal/vanilla install, and another for a "read-to-use" install with common logging configurations pre-enabled?

Not exactly. The fluent-operator chart provides everything you need for a fully-functional installation (including CRDs). The function of the fluent-operator chart doesn't really change from what it provides currently (in v3).

The fluent-operator-crds chart only includes the CRDs. Users can optionally use this chart if they want to manage the lifecycle of the CRDs separately using Helm.

2. Could we reconsider the naming to better differentiate the fluent-operator and fluent-operator-crd charts? The current naming might confuse users into thinking the standard fluent-operator chart doesn't include CRDs, and don't know which one to use.

I think it's pretty clear and standard (other projects follow a similar pattern). A user can just take a look at the crds/ directory to see they are included -- and the crds/ directory is the idiomatic location for CRDs in a helm chart. What would you suggest?

3. For the fluent-operator-crd chart, should it also include the deployment of the operator itself, or is it strictly for the CRDs?

No, it only includes CRDs. Usage of this chart is optional. Do you think the docs need clarifying?

[cw-Guo]

LGTM. Thank you!

[marcofranssen]

LGTM 🚀

Good work on moving all these pieces around.