first steps for kms key-ring resource and datasource #897
Conversation
|
This PR was marked as stale after 7 days of inactivity and will be closed after another 7 days of further inactivity. If this PR should be kept open, just add a comment, remove the stale label or push new commits to it. |
| panic("implement me") | ||
| } | ||
|
|
||
| func toCreatePayload(model *Model) (*kms.CreateKeyRingPayload, error) { |
There was a problem hiding this comment.
Please consider implementing a unit test for this func.
| }, nil | ||
| } | ||
|
|
||
| func mapFields(keyRing *kms.KeyRing, model *Model) error { |
| return &keyRingResource{} | ||
| } | ||
|
|
||
| type keyRingResource struct { |
There was a problem hiding this comment.
Don't know if you are aware of this, please don't forget to implement the import.
You can ensure this by adding the code below:
// Ensure the implementation satisfies the expected interfaces.
var (
_ resource.Resource = &keyRingResource{}
_ resource.ResourceWithConfigure = &keyRingResource{}
_ resource.ResourceWithImportState = &keyRingResource{}
)See the git instance resource how to do it:
Consider doing the same for the datasource, see the git instance datasource for example:
| } | ||
|
|
||
| func (k *keyRingResource) Metadata(ctx context.Context, request resource.MetadataRequest, response *resource.MetadataResponse) { | ||
| response.TypeName = request.ProviderTypeName + "kms_key_ring" |
There was a problem hiding this comment.
| response.TypeName = request.ProviderTypeName + "kms_key_ring" | |
| response.TypeName = request.ProviderTypeName + "_kms_key_ring" |
| KeyRingId types.String `tfsdk:"key_ring_id"` | ||
| Id types.String `tfsdk:"id"` // needed by TF | ||
| ProjectId types.String `tfsdk:"project_id"` | ||
| RegionId types.String `tfsdk:"region_id"` |
There was a problem hiding this comment.
| RegionId types.String `tfsdk:"region_id"` | |
| Region types.String `tfsdk:"region"` # small adjustment to stick with the naming conventions across the codebase |
According to https://docs.api.stackit.cloud/documentation/kms/version/v1beta , the KMS API already uses the new multi-region concept.
See e.g. the stackit_routing_table resource how to implement the multi-region concept. The resource has a region field which is marked as optional and will use the default_region configured in the provider as a fallback: https://registry.terraform.io/providers/stackitcloud/stackit/latest/docs/resources/routing_table
- You will need to store the provider configuration within your resource struct: and
- Field definition:
- Then use this helper func to read the region:
| if providerData.KMSCustomEndpoint != "" { | ||
| apiClientConfigOptions = append(apiClientConfigOptions, config.WithEndpoint(providerData.KMSCustomEndpoint)) | ||
| } else { | ||
| apiClientConfigOptions = append(apiClientConfigOptions, config.WithRegion(providerData.GetRegion())) |
There was a problem hiding this comment.
| apiClientConfigOptions = append(apiClientConfigOptions, config.WithRegion(providerData.GetRegion())) | |
| apiClientConfigOptions = append(apiClientConfigOptions)) |
Since the KMS API already implemented the new multi-region concept, you don't need to set the region here (or better: the SDK should throw an error if you do 😄 ).
Apart from that, consider adding a unit tests for this func, see e.g. https://github.com/stackitcloud/terraform-provider-stackit/blob/8e776757ea2280d1222afe50c3024945b4d99eed/stackit/internal/services/git/utils/util_test.go
Description
relates to #1234
Checklist
make fmtexamples/directory)make generate-docs(will be checked by CI)make test(will be checked by CI)make lint(will be checked by CI)