terraform-provider-opennebula
terraform-provider-opennebula copied to clipboard
cpu_model gets replaced every time
Description
cpu_model gets replaced every time
Terraform and Provider version
Provider version: 1.2.1 OpenNebula version: 6.4.0
Affected resources and data sources
template_section / cpu_model
Terraform configuration
template_section {
name = "cpu_model"
elements = {
model = "host-passthrough"
}
Expected behavior
+ template_section {
+ elements = {
+ "model" = "host-passthrough"
}
+ name = "cpu_model"
}
cpu_model should not be replaced after provisioning
Actual behavior
cpu_model is replaced every time. - cpumodel { - model = "host-passthrough" -> null }
Steps to Reproduce
Add the terraform configuration from above and try to provision a VM.
Debug output
No response
Panic output
No response
Important factoids
No response
References
No response
It seems cpumodel
sections of the virtual machine resource is missing in the documentation, we need at least a PR to update the documentation.
See an usage example here: https://github.com/OpenNebula/terraform-provider-opennebula/blob/master/opennebula/resource_opennebula_virtual_machine_test.go#L605 Feel free to drop a comment if it works as expected, or not
If I use cpumodel as specified in the https://github.com/OpenNebula/terraform-provider-opennebula/blob/master/opennebula/resource_opennebula_virtual_machine_test.go#L605
The feature is added,
CPUMODEL = [
MODEL = "host-passthrough" ]
DESCRIPTION = "Uses Proton default image that enables root login with a simple password; must not use outside of testing."
SCHED_REQUIREMENTS = "CLUSTER_ID=\"308\" "
but ignored, by OpenNebula.
Update: Works properly with
model = "host-passthrough"
}
but IMO should be renamed. Adding this PR here since I allready have it. https://github.com/OpenNebula/terraform-provider-opennebula/pull/454
TODO: add a docs PR regardless of the approach.
On the same page, setting the cpumodel to "" should have the same behavior as seting it to default. As far as I can tell default is "" but in the background opennebula assigns it to qemu64, even tough the GUI displays it as blank.
Currently setting it cpumodel to "" crashes the plugin.
cpumodel {
model = ""
}
module.vmk["vmk-dev-intel-01"].netbox_primary_ip.primary_ip: Creation complete after 1s [id=1326]
╷
│ Error: Plugin did not respond
│
│ with module.vmk["vmk-dev-intel-01"].opennebula_virtual_machine.vm,
│ on ../single-vm/main.tf line 56, in resource "opennebula_virtual_machine" "vm":
│ 56: resource "opennebula_virtual_machine" "vm" {
│
│ The plugin encountered an error, and failed to respond to the
│ plugin.(*GRPCProvider).ApplyResourceChange call. The plugin logs may
│ contain more details.
╵
Stack trace from the terraform-provider-opennebula_v1.2.1 plugin:
panic: interface conversion: interface {} is nil, not map[string]interface {}
goroutine 48 [running]:
github.com/OpenNebula/terraform-provider-opennebula/opennebula.generateVMTemplate(0xc68720?, 0xc000716708)
github.com/OpenNebula/terraform-provider-opennebula/opennebula/shared_schemas.go:609 +0xae6
github.com/OpenNebula/terraform-provider-opennebula/opennebula.generateVm(0xc000326a68?, {0xc3f800?, 0xc000696ac0}, 0xc000350060)
github.com/OpenNebula/terraform-provider-opennebula/opennebula/resource_opennebula_virtual_machine.go:2220 +0x34d
github.com/OpenNebula/terraform-provider-opennebula/opennebula.resourceOpennebulaVirtualMachineCreate({0xe81f48, 0xc0006921e0}, 0xc000128180, {0xc3f800?, 0xc000696ac0})
github.com/OpenNebula/terraform-provider-opennebula/opennebula/resource_opennebula_virtual_machine.go:288 +0x305
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).create(0xc0004a3b20, {0xe81f80, 0xc0005f87b0}, 0xd?, {0xc3f800, 0xc000696ac0})
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:707 +0x12e
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).Apply(0xc0004a3b20, {0xe81f80, 0xc0005f87b0}, 0xc0005fb2b0, 0xc000128980, {0xc3f800, 0xc000696ac0})
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:837 +0xa7a
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ApplyResourceChange(0xc00000d728, {0xe81f80?, 0xc0005f8690?}, 0xc0005320f0)
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:1021 +0xe3c
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ApplyResourceChange(0xc00009f4a0, {0xe81f80?, 0xc0005f8000?}, 0xc000626070)
github.com/hashicorp/[email protected]/tfprotov5/tf5server/server.go:818 +0x574
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ApplyResourceChange_Handler({0xd03360?, 0xc00009f4a0}, {0xe81f80, 0xc0005f8000}, 0xc000626000, 0x0)
github.com/hashicorp/[email protected]/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:385 +0x170
google.golang.org/grpc.(*Server).processUnaryRPC(0xc0000003c0, {0xe85180, 0xc00050c820}, 0xc0005c8360, 0xc00048b6b0, 0x136f660, 0x0)
google.golang.org/[email protected]/server.go:1340 +0xd13
google.golang.org/grpc.(*Server).handleStream(0xc0000003c0, {0xe85180, 0xc00050c820}, 0xc0005c8360, 0x0)
google.golang.org/[email protected]/server.go:1713 +0xa1b
google.golang.org/grpc.(*Server).serveStreams.func1.2()
google.golang.org/[email protected]/server.go:965 +0x98
created by google.golang.org/grpc.(*Server).serveStreams.func1
google.golang.org/[email protected]/server.go:963 +0x28a
Error: The terraform-provider-opennebula_v1.2.1 plugin crashed!
This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.
I'll close this one, and open a new one for what I've found.
Reopening, as this bug still remains
Setting model to "" does not revert back to default model.
cpumodel {
model = ""
}
This issue is stale because it has been open for 30 days with no activity and it has not the 'status: confirmed' label or it is not in a milestone. Remove the 'status: stale' label or comment, or this will be closed in 5 days.
It seems that CPU_MODEL->MODEL feature works correctly. The caveat is that we can't really modify cpu model in a running VM. Rebooting the VM is not enough, it must be powered down then resumed (by the user), only then vm.xml can be (and is) properly regenerated. So in the end, we allow such model change but it's not immediate. There is no auto-poweroff/on feature in OpenNebula, so we won't implement it in the provider either. :)