Using ConflictsWith in a TypeSet not possible

[Junkern]

SDK version

v2.18.0

Relevant provider source code

"registry_auth": {
					Type:     schema.TypeSet,
					Optional: true,
					Elem: &schema.Resource{
						Schema: map[string]*schema.Schema{
							"address": {
								Type:        schema.TypeString,
								Required:    true,
								Description: "Address of the registry",
							},

							"username": {
								Type:          schema.TypeString,
								Optional:      true,
								ConflictsWith: []string{"registry_auth.config_file", "registry_auth.config_file_content"},
								DefaultFunc:   schema.EnvDefaultFunc("DOCKER_REGISTRY_USER", ""),
								Description:   "Username for the registry",
							},

							"password": {
								Type:          schema.TypeString,
								Optional:      true,
								Sensitive:     true,
								ConflictsWith: []string{"registry_auth.config_file", "registry_auth.config_file_content"},
								DefaultFunc:   schema.EnvDefaultFunc("DOCKER_REGISTRY_PASS", ""),
								Description:   "Password for the registry",
							},

							"config_file": {
								Type:          schema.TypeString,
								Optional:      true,
								ConflictsWith: []string{"registry_auth.username", "registry_auth.password", "registry_auth.config_file_content"},
								DefaultFunc:   schema.EnvDefaultFunc("DOCKER_CONFIG", "~/.docker/config.json"),
								Description:   "Path to docker json file for registry auth",
							},

							"config_file_content": {
								Type:          schema.TypeString,
								Optional:      true,
								ConflictsWith: []string{"registry_auth.username", "registry_auth.password", "registry_auth.config_file"},
								Description:   "Plain content of the docker json file for registry auth",
							},
						},
					},
				},

(Taken from here) kreuzwerker/terraform-provider-docker#400

Terraform Configuration Files

not applicable

Debug Output

ConflictsWith: username configuration block reference (registry_auth.config_file) can only be used with TypeList and MaxItems: 1 configuration blocks

Expected Behavior

I expect that I can have a Set and every item of the set can only have non-conflicting elements.
E.g. the first item of the registry_auth set has username && password. The second item has config_file.

I assume that this is not possible at the moment and I have to do the conflicts validation manually in the code?

Actual Behavior

Error message is seen in Debug Output secetion

References

• Using ConflictsWith with Lists or Sets #71
• Can't set ConflictWith against field in the nested block #888

[bflad]

Hi @Junkern 👋 Thank you for raising this and sorry you ran into this potentially frustrating situation.

I assume that this is not possible at the moment and I have to do the conflicts validation manually in the code?

To answer your question there directly, yes. I'll explain below.

Sets are conceptually an interesting implementation detail within the Terraform type system as each element is "indexed" by its entire value, rather than something that can be indexed by an ordering of the elements like a list. Values of every type in Terraform, in terms of set "indexing", can be either null, unknown, or a unique known value. Effectively in real world usage, Terraform opts to say that "indexing" into sets is generally not supported because of the inherent complexity of this implementation detail. As a set value becomes more complex in schema details, there are exponentially growing cases to account for that are non-intuitive to implement the set value for "indexing" purposes. In the case of set blocks in the SDK, that Terraform type is a set of objects with further attributes/blocks. Every attribute's null/unknown/known value would need to be accounted for if "indexing" was supported. Additionally, the syntax provided to ConflictsWith and other path-based functionality would need to be able to support these currently unsupported concepts.

The SDK could potentially try to paper over this implementation detail (or limitation, if you will), however, ensuring the validity of a proper set element match would likely be jeopardized since each of those underlying details is important. I also personally think the syntax discussion is a non-starter.

There are however, other possible approaches to this problem that can avoid this set "indexing" issue. For example, supporting relative attribute paths in SDK functionality would allow provider developers to start within an attribute in an already calculated set object path, step backwards once to the parent (the set object), then step forwards into different attribute within the same set object. The discussions surrounding this are captured in #71, which is considered a feature request to this project.

Because there is already an existing feature request for this type of functionality and the answer to your question seems to be a binary yes/no that I hopefully covered for you, I'm going to close this issue in preference of the existing one to consolidate any discussions or efforts.

---

Aside: The team that maintains this SDK has been mainly focusing development efforts on terraform-plugin-framework, which reimagines the provider developer experience from the ground up. In that project, there has been some very recent work done to explore this space, and an initial implementation is being finalized (but not quite released) that supports these more advanced path handling concepts. Here are some links to that project if you haven't seen it before and to tease out how this initially looks over there:

• https://www.terraform.io/plugin/framework
• https://github.com/hashicorp/terraform-plugin-framework/pull/413/files#diff-782454f5e7f673ccaaba516b469039d2f608da122a13b6857f91230a81147ae8

[Junkern]

Thanks a lot for your thorough response, I really appreciate that!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.