The user reports that configuring a rancher_catalog_v2 resource with the ca_bundle field set fails. This is because the caBundle field in the configured ClusterRepo resource is base64-encoded twice. For more details, the JIRA issue gives a pretty good description.
Also note that there is a discrepancy between the documentation for configuring a repo/catalog via the Rancher UI, and the documentation for the ca_bundle field in the rancher_catalog_v2 resource:
Git-based chart repositories: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo link
ca_bundle - (Optional) PEM encoded CA bundle which will be used to validate the repo's certificate (string) link
Solution
The cleanest solution, as far as @nicholasSUSE and I can tell, is to slightly change the behavior of the ca_bundle field so that the user sets it to a base64-encoded DER value. When expanding the terraform object into a ClusterRepo, the rancher2 provider base64-decodes the passed ca_bundle value and sets the spec.caBundle field of the ClusterRepo to the result, which is of type []byte. When the encoding/json package marshals the ClusterRepo struct created by the rancher2 provider, it automatically base64-encodes the caBundle field (see the docs for json.Marshal), which appears to be what the Rancher API expects.
Testing
This issue can be reproduced by running the terraform provider against a v2.7.6 Rancher cluster. Note that running it against a version of Rancher run via go run main.go or dlv doesn't work - it seems that the terraform provider chokes on the fact that something (I never figured out what) has the version dev.
Engineering Testing
Manual Testing
On a Rancher v2.7.6 deployment running in k3d, I did the following tests using the terraform provider:
Creating a ClusterRepo resource with the caBundle field set.
Creating a ClusterRepo resource without the caBundle field set.
Deleting a ClusterRepo resource.
Updating a ClusterRepo resource by changing the name field in the terraform resource. This failed, but I determined that this failure is present on the master branch and thus not related to this PR. This seems wrong to me, but also seems like it may just be due to how the Rancher API works. I'm new to the Rancher project, so can someone who has more experience with Rancher check this?
Automated Testing
I updated the ca_bundle field in the expandCatalogV2 and flattenCatalogV2 unit tests to reflect the HCL value being base64-encoded DER, and the ClusterRepo value being a []byte containing unencoded DER.
QA Testing Considerations
I don't think there is any issue with changing the behavior of the ca_bundle field, since it is broken as is. I could easily be wrong though...
Issue:
For rancher/terraform-provider-rancher2#1297
Problem
The user reports that configuring a
rancher_catalog_v2resource with theca_bundlefield set fails. This is because thecaBundlefield in the configuredClusterReporesource is base64-encoded twice. For more details, the JIRA issue gives a pretty good description.Also note that there is a discrepancy between the documentation for configuring a repo/catalog via the Rancher UI, and the documentation for the
ca_bundlefield in therancher_catalog_v2resource:Solution
The cleanest solution, as far as @nicholasSUSE and I can tell, is to slightly change the behavior of the
ca_bundlefield so that the user sets it to a base64-encoded DER value. When expanding the terraform object into aClusterRepo, therancher2provider base64-decodes the passedca_bundlevalue and sets thespec.caBundlefield of theClusterRepoto the result, which is of type[]byte. When theencoding/jsonpackage marshals theClusterRepostruct created by therancher2provider, it automatically base64-encodes thecaBundlefield (see the docs forjson.Marshal), which appears to be what the Rancher API expects.Testing
This issue can be reproduced by running the terraform provider against a v2.7.6 Rancher cluster. Note that running it against a version of Rancher run via
go run main.goordlvdoesn't work - it seems that the terraform provider chokes on the fact that something (I never figured out what) has the versiondev.Engineering Testing
Manual Testing
On a Rancher v2.7.6 deployment running in k3d, I did the following tests using the terraform provider:
ClusterReporesource with thecaBundlefield set.ClusterReporesource without thecaBundlefield set.ClusterReporesource.ClusterReporesource by changing thenamefield in the terraform resource. This failed, but I determined that this failure is present on themasterbranch and thus not related to this PR. This seems wrong to me, but also seems like it may just be due to how the Rancher API works. I'm new to the Rancher project, so can someone who has more experience with Rancher check this?Automated Testing
I updated the
ca_bundlefield in theexpandCatalogV2andflattenCatalogV2unit tests to reflect the HCL value being base64-encoded DER, and the ClusterRepo value being a[]bytecontaining unencoded DER.QA Testing Considerations
I don't think there is any issue with changing the behavior of the
ca_bundlefield, since it is broken as is. I could easily be wrong though...Regressions Considerations