Missing documentation on policy for 'option defaults'

[dirkmueller]

System Information

SLES15 SP2 with terraform-provider-libvirt master.

Description of Issue/Question

I am missing the description of how the 'defaults' of the terraform libvirt provider are being set. for example the default graphics card is set to 'cirrus'. Now this is fine (I think it is also the qemu default graphics card for x86_64), however this graphics card does not exist on non-x86.

For example on arm64, the supported/recommended graphics card would be the 'virt' graphics card (which is virtio-gpu, a special graphics card that always works inside KVM and is accelerated over the unaccelerated 'emulating' graphics cards).

Therefore I'm wondering if it would be better to switcht the default 'globally' to 'virt' (as it also works on x86, however would be backward incompatible), or switch the default to 'virt' only for aarch64, or document which changes need to be done to make things for out of the box for aarch64.

What I'm trying to achieve is with as minimum as possible hackery in the actual terraform templates (.tf) files make a deployment possible on multiple architectures. right now there are a lot of architecture specific changes needed because things are slightly different depending on which architecture it is.

Expected outcome

I would like to see a policy documentation on 'defaults' for the options. Is it supposed to model the libvirtd defaults as closely as possible? or does the provider want to have its own opinionated defaults that work well across a range of 'target' platforms/deployments?

[MalloZup]

@dirkmueller yes I agree with you.
I think historically this provider was build on x86 so some parameter are just hardcoded to x64 and other archs was not test

Regarding your legitimate questions, by design we didn't want to go 1:1 with libvirtd defaults, or at least when providing support to all libvirt flags . This was also why the xslt feature was merged, in order to add custom xml fields without need to maintain them. ( was a compromise between accepting to much change and possible bugs which can occur)

So imho, if we have acceptable defaults for all platform we can merge this issue by issue.

I think also documenting or providing an working example (https://github.com/dmacvicar/terraform-provider-libvirt/tree/master/examples) is also something we can do if the change of the code are to radical or disruptive

[scabala]

Related to #961.

I think this is not a big deal - it's just a default that can be changed.

[dmacvicar]

I think we could refactor lot of code that sets conditionally things on architecture with a table of defaults by architecture.