Enable CRD validation generation for Helm and Ansible

[camilamacedo86]

Feature Request

Is your feature request related to a problem? Please describe.

When we scaffold a project using a chart for example, the CRs will be automatically created with the chart values but the CRD will not be created with these data.

For Go, the CRDs are updated when we run make manifests via controller-gen and because of this, the projects pass by default in the scorecard-test olm-crds-have-validation which is not achievable with Helm or Ansible.

For reference using helm operator-sdk-sample:

$ cd ~/devel/operator-sdk-samples/helm/memcached-operator
$ operator-sdk scorecard ./bundle --selector=suite=olm

SNIP...
--------------------------------------------------------------------------------
Image:      quay.io/operator-framework/scorecard-test:master
Entrypoint: [scorecard-test olm-crds-have-validation]
Labels:
	"suite":"olm"
	"test":"olm-crds-have-validation-test"
Results:
	Name: olm-crds-have-validation
	State: fail

	Suggestions:
		Add CRD validation for spec field `metrics` in Memcached/v1alpha1
		Add CRD validation for spec field `podAnnotations` in Memcached/v1alpha1
		Add CRD validation for spec field `updateStrategy` in Memcached/v1alpha1
		Add CRD validation for spec field `extraContainers` in Memcached/v1alpha1
		Add CRD validation for spec field `image` in Memcached/v1alpha1
		Add CRD validation for spec field `kind` in Memcached/v1alpha1
		Add CRD validation for spec field `pdbMinAvailable` in Memcached/v1alpha1
		Add CRD validation for spec field `replicaCount` in Memcached/v1alpha1
		Add CRD validation for spec field `securityContext` in Memcached/v1alpha1
		Add CRD validation for spec field `tolerations` in Memcached/v1alpha1
		Add CRD validation for spec field `affinity` in Memcached/v1alpha1
		Add CRD validation for spec field `memcached` in Memcached/v1alpha1
		Add CRD validation for spec field `resources` in Memcached/v1alpha1
		Add CRD validation for spec field `serviceAnnotations` in Memcached/v1alpha1
		Add CRD validation for spec field `AntiAffinity` in Memcached/v1alpha1
		Add CRD validation for spec field `nodeSelector` in Memcached/v1alpha1
		Add CRD validation for spec field `extraVolumes` in Memcached/v1alpha1
	Log:
		Loaded 1 Custom Resources from alm-examples
		Loaded CustomresourceDefinitions: [&CustomResourceDefinition{ObjectMeta:{memcacheds.cac

Describe the solution you'd like

Have a target similar to make manifests for Helm/Ansible.

Maybe we could implement a similar feature which would:

• For Helm: Parse the chart values and update the CRD
• For Ansible: Parse the default/main.yaml and update the CRD

[joelanford]

IMO, we should rely on upstream support for schema validation specifications. See Helm v3's new support, for example: helm/helm#5081

[joelanford]

See also: https://helm.sh/docs/topics/charts/#schema-files

[camilamacedo86]

I will check it as discussed in the meeting triage.
We might need to push changes in the upstream in order to let us know easily what would be the attributes and types.

[camilamacedo86]

Hi @joelanford,

I could check this chart schema(helm/helm#5350). See its doc:

values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file

So, for Helm, we could address it by using this schema. Also, if we would like to parse the YAML file and get the attributes and its types to create a make manifests for Helm/Ansible we could do something such as too:

package main

import (
	"fmt"
	"reflect"
	"sigs.k8s.io/yaml"
)

var file = `---
foo1:
  bar:
    - bar
    - rab
    - plop
foo2: bar
foo3: 1
foo4: true
foo5: 1.4
foo8:
  - bar
  - rab
  - plop
`

func main() {
	var data map[string]interface{}
	yaml.Unmarshal([]byte(file), &data)
	for key, value := range data {
		valueType := reflect.TypeOf(value).Kind().String()
		fmt.Println("Attribute:", key, "Type:", valueType )
	}
}

Result:

Attribute: foo1 Type: map
Attribute: foo2 Type: string
Attribute: foo3 Type: float64
Attribute: foo4 Type: bool
Attribute: foo5 Type: float64
Attribute: foo8 Type: slice

[camilamacedo86]

The EP operator-framework/enhancements#25 for OLM also shows requires to parse the chart values to create the manifests.

[joelanford]

I have a working branch that uses values.schema.json if it is present in a chart.

While developing it, I noticed that Kubernetes API server is fairly strict on what it expects to be present or not present in the CRD validation section when converting from values.schema.json.

This is a UX problem because the CRD generation appears to work correctly, but an error is surfaced much later when one actually attempts to create the CRD in a cluster. IMO that is a bad user experience, and one we should try to avoid.

[camilamacedo86]

The end goal of this issue would be we have a makefile target manifests for Ansible/Go. I will update the first comment to clarifies it. It cames in the survey so, I am removing the milestone for we have the chance to discuss it again in the bug triage.