Open VoyTechnology opened 5 years ago
I believe the setup should look similar to how AWS AMI is created: https://www.terraform.io/docs/providers/aws/r/ami.html
resource "virtualbox_image" "ubuntu" {
location = "https://app.vagrantup.com/ubuntu/boxes/bionic64/versions/20180903.0.0/providers/virtualbox.box"
dynamic = false
size = "8GB"
}
resource "virtualbox_disk" "storage" {
size = "100GB"
dynamic = false
}
resource "virtualbox_vm" "node" {
...
disk {
device_id = virtualbox_image.ubuntu.id
mount_path = "/"
}
disk {
device_id = virtuabox_disk.storage.id
mount_path = "/var/data"
}
}
I have no real experience with vagrant box format, and I have always done thing with iso+install, so this might not be 100% accurate, but this is how I would see it working. I am also not sure about disk.device_id
, maybe alternative name, or method of getting details about which disk to actually use. What's your opinion @ringods.
Perhaps the virtualbox_image
can only be a data source, since its just getting stuff from remote location.
@VoyTechnology I can follow your thinking of it being a datasource
, but the question really is: where is the user manipulating the image: remotely or locally?
I am tempted to say locally and that means it should be a resource
. Expressed in the different Terraform callback functions for a resource:
Exists
: Is the image already available as a registered image in your local Virtualbox?Create
: download the remote image, unpack it and register it locally in VirtualboxRead
: fetch the actual information of the locally registered imageUpdate
: not sure whether this is applicable. If one would change the remote URL, I would say this means a Delete
(old) + Create
(new)Delete
: unregister the image and cleanup all local files.I would not model it as the AWS ami
resource which creates a new AMI. Creating images is better done with Packer
The
resource_vm
is responsible for the whole lifetime of a VM. We should detach the responsibility of creating the virtual disk and delegate it toresource_disk
, which can be controlled independently of the VM.