adding values-parity.yaml to the project again

[ArshamTeymouri]

@chevdor According to your comment on #370 (comment), I moved the parity's values file to the could-infra repository, but the CI stopped working because the substrate-telemetry Gitlab repository doesn't have access to read the files from cloud-infra. For granting access, an access token should be configured for substrate-telemetry repository to be able to fetch files from the cloud-infra, but it might have its own security concerns again.

I would suggest leaving it like this for now to have at least a working CI pipeline then I would consult with Gabriel about this specific project and once we find the proper solution, we would remove the file from here again.

[jsdw]

I'm happy with this if you guys are :)

[chevdor]

As I initially mentioned we should keep values.yml "standard" (=non parity). I see no issue in the short term having an extra values-parity.yml in the repo.

Don't you need to tell CI to use values-parity.yml instead of values.yml or it it fine to let the CI run on the new standard values.yml ?

[ArshamTeymouri]

Don't you need to tell CI to use values-parity.yml instead of values.yml or it it fine to let the CI run on the new standard values.yml ?

@chevdor it's already done, the helm chart uses the values-parity.yaml file.

After discussing this with Gabriel, we decided to put the custom values file in a Kubernetes configmap and fetch it with kubectl command line in the CI before applying the helm chart.