Set/list attribute migration from SDKv2 to framework

Terraform Providers Plugin Development
2

Hi @yec-akamai :wave:

It sounds like you’ve already looked through the documentation for migrating blocks from SDKv2 to the Framework.

In terms of using a nested block, then if you need to make supplying of Terraform configuration for the block optional and you have a Required attribute on the block then you won’t be able to use a SingleNestedBlock, for instance:

		Blocks: map[string]schema.Block{
			"b": schema.SingleNestedBlock{
				Attributes: map[string]schema.Attribute{
					"attr_1": schema.Int64Attribute{
						Required: true,
					},
					"attr_2": schema.BoolAttribute{
						Optional:    true,
					},
				},
			},
		},

This is because omission of configuration for the block will give rise to the following error:

│ Must set a configuration value for the b.attr_1 attribute as the provider has marked it as required.

However, you could use SetNestedBlock and add a validator, for example:

		Blocks: map[string]schema.Block{
			"b": schema.SetNestedBlock{
				NestedObject: schema.NestedBlockObject{
					Attributes: map[string]schema.Attribute{
						"attr_1": schema.Int64Attribute{
							Required: true,
						},
						"attr_2": schema.BoolAttribute{
							Optional:    true,
						},
					},
				},
				Validators: []validator.Set{
					setvalidator.SizeAtMost(1),
				},
			},
		},

The error that you describe (in points 2. and 3.) is a consequence of the value for the block being altered from the value defined in the Terraform configuration. This error is expected as Terraform will not allow modification of data that was supplied through the configuration, including cases in which no configuration was supplied as the expectation is then that the value will be null.

If there are “computed” values that are being obtained from an API call, for instance, and these need to be persisted then you will need to amend your schema to include an additional computed attribute or attributes. Note that addition of a computed attribute or attributes represents a breaking change but this may be unavoidable depending upon whether you need to persist the data returned from your API call or not. There is discussion around a similar use-case in Optional Computed Block handling in Plugin Framework

1 Like