Previously, the CPI wrote the CA certs for vCenter, NSX, and NSX-T to disk as part of BOSH templating. This works correctly for environments with a single CPI config. However, in environments that have 2 or more vSphere CPI configs, the CA certs for the specific config used are passed at runtime by the BOSH Director when invoking the CPI. The CPI was always using the CA certs rendered to disk, meaning the CAs in other CPI configs would be ignored and could cause TLS verification failures during the deploy.
Now, instead of rendering the CA certs to disk during BOSH templating, they are written to disk as temporary files once the updated config for the specific CPI is received and merged (the context variable in the lambda in the vsphere_cpi executable). Temporary files were chosen rather than re-writing the templated file to avoid problems when multiple CPI invocations occur concurrently.
Previously, the CPI wrote the CA certs for vCenter, NSX, and NSX-T to disk as part of BOSH templating. This works correctly for environments with a single CPI config. However, in environments that have 2 or more vSphere CPI configs, the CA certs for the specific config used are passed at runtime by the BOSH Director when invoking the CPI. The CPI was always using the CA certs rendered to disk, meaning the CAs in other CPI configs would be ignored and could cause TLS verification failures during the deploy.
Now, instead of rendering the CA certs to disk during BOSH templating, they are written to disk as temporary files once the updated config for the specific CPI is received and merged (the
contextvariable in the lambda in thevsphere_cpiexecutable). Temporary files were chosen rather than re-writing the templated file to avoid problems when multiple CPI invocations occur concurrently.