Docker plain helm chart

[segfault16]

Add helm chart for docker plain

Refers to #1013

Tasks:

• Updated documentation in docs/modules/... directory
• Ran tests in <quickstarter>/testdata directory
• Shared library adaptions

[faust2199]

Having a very strict values.schema.json is probably not going to provide good experience when using helmValues defined from the Jenkinsfile. According to https://helm.sh/docs/topics/charts/ , "the schema is applied to the final .Values object, and not just to the values.yaml file."

Let's say we have the following in the Jenkinsfile:
odsComponentStageRolloutOpenShiftDeployment(context, [ 'selector': "app.kubernetes.io/name=${context.componentId}", 'helmEnvBasedValuesFiles': ['values.env.yaml'], 'helmValues': [ 'foo': 'bar' ] ]

When the above runs on Jenkins, ods-jenkins-shared-library will add two arguments on the command line:
--set foo=bar --set global.foo=bar

Then it will be aborted because additionalProperties are not allowed in both places. Is the user really expected to add two entries in values.schema.json to fix this?

I suggest that we remove the whole values.schema.json file. If the result of rendering is bad, helm upgrade is going to fail and rollback anyway.

[renedupont]

Having a very strict values.schema.json is probably not going to provide good experience when using helmValues defined from the Jenkinsfile. According to https://helm.sh/docs/topics/charts/ , "the schema is applied to the final .Values object, and not just to the values.yaml file."

Let's say we have the following in the Jenkinsfile: odsComponentStageRolloutOpenShiftDeployment(context, [ 'selector': "app.kubernetes.io/name=${context.componentId}", 'helmEnvBasedValuesFiles': ['values.env.yaml'], 'helmValues': [ 'foo': 'bar' ] ]

When the above runs on Jenkins, ods-jenkins-shared-library will add two arguments on the command line: --set foo=bar --set global.foo=bar

Then it will be aborted because additionalProperties are not allowed in both places. Is the user really expected to add two entries in values.schema.json to fix this?

I suggest that we remove the whole values.schema.json file. If the result of rendering is bad, helm upgrade is going to fail and rollback anyway.

I partially agree, I think there is a middle way though. In the values.schema.json we could set "additionalProperties": false to true in the relevant parts. That way we validate everything that is set in that file and everything else will not be considered and not lead to failing the helm validation.

[jafarre-bi]

A few new comments and some conversations still open.

[jafarre-bi]

Why is this selector only the name? chart.selectorLables are, as they should, name + instance.

[faust2199]

Why is this selector only the name? chart.selectorLables are, as they should, name + instance.

Do you mean https://kubernetes.io/docs/reference/labels-annotations-taints/#app-kubernetes-io-instance? How do we generate the unique postfix like in the example given "mysql-abcxyz"?

[jafarre-bi]

@faust2199 Unless there's something I'm missing, the deployment.yaml is using chart.selectorLabels for the selector. This is defined in _helpers.tpl to be name = chart.name and instance = .Release.Name. Whatever we use it must match the actual selectors used in deployments, services...

[jafarre-bi]

My questions here are:

1. Is the chart name always equal to the componentId?
2. Will the functionality of getting resources based only on the name label never return resources that shouldn't match?
3. Is it correct to specify this selector in the deployment mean when the actual selector used is different? (For this I would answer no)

[jafarre-bi]

The Release Manager doesn't support multiple replicas yet. Not sure if these values should even be configurable, or at least maxReplicas should be 1 by default, with a comment saying that higher values aren't supported.

[segfault16]

@jafarre-bi I don't know about this limitation, there's nothing in opendevstack documentation about. Please provide the source

[jafarre-bi]

@segfault16 HelmDeploymentStrategy, line 198:
// TODO: Once the orchestration pipeline can deal with multiple replicas,
// update this to store multiple pod artifacts.
Even if the code could deal with it and the documentation and traceability would be correctly preserved, it's still not officially supported. We would need to validate the functionality, document it and create specific automated tests to prevent regressions.