Additional non-schema default values

Hi,

I have an API which models a plugins scheme which has a basic configuration block of tables/fields, i have a trivial schema below to show.

map[string]*schema.Schema{
		"plugin_ref": {
			Type:     schema.TypeString,
			Required: true,
		},
		"configuration": {
			Type:     schema.TypeList,
			Optional: true,
			MaxItems: 1,
			Elem: &schema.Resource{
				Schema: map[string]*schema.Schema{
					"fields": {
						Type:     schema.TypeSet,
						Optional: true,
						Elem: schema.Resource{
							Schema: map[string]*schema.Schema{
								"name": {
									Type:     schema.TypeString,
									Required: true,
								},
								"value": {
									Type:     schema.TypeString,
									Optional: true,
								},
								//...
							},
						},
					},
				},
			},
		},
	}

Now this results in tf code like this:

plugin_ref = "com.foo.bar"
configuration {
    fields {
      name  = "field1"
      value = "foo"
    }

    fields {
      name  = "field2"
      value = "3"
    }

The actual fields have a few other schema elements I have omited for simplicity here.

Whilst this works fine, quite of a few of the plugins have ALOT of default configuration, but because in the provider im modeling the API which has the plugin schema (not each plugins implementation) I can’t set any of the defaults on the scheme itself.

I can read the plugins definition from the server and check what has been provided in the configuration blocks and add any unset defaults, so with the terraform code above if i have the plugin com.foo.bar and it has a 3rd required field field3 with a default of true i can query the API to get all the defaults to ensure any request is correct. However the problem comes when i try to set the state so im not constantly seeing changes in the plan?

Is it possible to set new configuration i.e to add the extra fields element?

Another question: I came across https://github.com/hashicorp/terraform-plugin-sdk/issues/112 highlighting #248 or #261 as potential solutions, is this still the case?

Hey @iwarapter,

The details on 112 are still, to the best of my knowledge, correct.

Am I correct in summarizing the problem you’re facing is that you have an entire block that’s got a default value set by the API, and you’re trying to figure out how to set that block in state without showing a diff?

Hi @paddy

I found a neat workaround for 112 (i did a depth set recursive function to build the schema).

Yes I think that summary is correct - i’d just trying to make my user experience more friendly by setting all the defaults where possible - without insisting the user pastes in loads of boiler plate code.

Setting Optional: true and Computed: true on the block that has the default should prevent a diff, just beware the consequences of that.