Add volume_attachment resources or equivalent about terraform-provider-libvirt

[inercia]

Maybe we can find a solution in the context proposed in #46 ...

[moio]

@inercia I do not think this is related.

Besides the fact I would agree with closing #46 the RFC is about embedding parameters for the ephemeral, "must-have" OS basic volume in the domain resource, while this is about extra "data" disks which might or might be there - hence in variable quantity.

[moio]

My proposal would be to add a disk_ids list in the domain resource, which could be populated via variables or interpolation.

This could even supersede the current disk variable, unless there is a reason I cannot see for keeping one map object instead of a plain id.

@flavio, @dmacvicar?

[moio]

Note this comment about disk_ids not being the right way to address this: #81 (comment)

[moio]

Asked HashiCorp if this is a core issue or by design.

[tboerger]

I would take other providers as a template, Scaleway got a comparable approach.

[moio]

OK, seems it's possible to fix this on our side, accepting maps and not objects for the disk block. This would be completely backwards compatible and would allow interpolations/variables to work in the most flexible way.

https://gitter.im/hashicorp-terraform/Lobby?at=581793b5806316005dde1c80
https://github.com/hashicorp/terraform/blob/master/builtin/providers/heroku/resource_heroku_app.go#L111

I will probably attempt a pull request soon.

[moio]

Correct solution should be, from my point of view, #83

[moio]

PR merged, closing.