Helm: Enhancements and fixes

[emiran-orange]

This PR brings some enhancements regarding Helm best practices and fixes regarding underlying hosts:

Fixes:

• Ability to mount Systemd journal in pods (systemdHost boolean in values.yaml) as drivers logs being written via unix socket /dev/log
• Ability to set the path where binaries are present on the underlying host (hostBinariesPath in values.yaml)

Enhancements:

• namespaceOverride in values.yml to get rid of NS creation which is not to be expected in a helm chart (with addition of related template in _helpers.tpl)
• PodsecurityPolicy (if pspEnabled is true in values.yaml)
• Use of templated values instead hardcoded ones in resources manifests
• Images, tags and pull policies have their variables in values.yaml so they can be overridden

[gil-excelero]

@emiran-orange Thank you for taking the time to create the PR, I have reviewed your changes and have a few comments and questions:

hostBinariesPath in values.yaml - could you explain the use-case for this parameter ?

namespaceOverride - I agree that the namespace object should not be created, and all namespaces should change to default (or be omitted), but I think the namespaceOverride parameter is redundant, it is possible to install in different namespaces by using the --namepsace falg, i.e: helm install <name> ./chart.tar --namespace <x>, this should override all namespace values in all templates

[emiran-orange]

hostBinariesPath allow to define a different path from the hardcoded "/bin" in case nvmesh binaries are not installed in /bin on the host.
On ubuntu, binaries seem to be installed in /usr/bin

[emiran-orange]

Regarding namespaceOverride, I agree that in most use-cases one won't need to define it.
I thought that the presence of a "namespace" key in the original values.yaml file was a way to handle some corner-cases where k8s objects should be defined in a different ns than the helm release.
This is the approach some of charts providers have taken (like helm/charts#18986 or helm/charts#15202).
BTW I'm fine with getting rid of it if you don't think it should be handled

[gil-excelero]

We don't have objects in different namespaces, so we can get rid of all metadata.namespace fields.
The only places where we still need to define a namespace are in the RBAC yaml file in each RoleBinding / ClusterRoleBinding in the field subjects[n].namespace and there we can use {{.Release.namespace}} instead of {{ .Values.namespace }}

[emiran-orange]

@gil-excelero I don't follow you, we cannot get rid of metadata.namespace, it should be in every manifest.
Moreover, I didn't say objects are/should be in different ns but I was pointing out the fact that some use-cases (like the ones described the mentioned PR) may require that the namespaceOverride feature

[gil-excelero]

@emiran-orange sorry for being unclear, I looked over it again, and it seems we do need the .Values.namespace to use when we run helm template to create a deployment.yaml file. in this case the Release.Namespace is not available and that's why we had the .Values.namespace in the first place. I also looked again at your implementation in _helpers and it seems to cover also the helm-template use-case. I will approve and merge.

[emiran-orange]

Great! Thanks