upvote for this from me - although our use case is slightly different; we need volume backed disks so that we can do backups from Cinder and also dynamic volume resize. So our block would look like this:
"block_device_mapping_v2": [{ "boot_index": "0", "uuid": "ac408821-c95a-448f-9292-73986c790911", "source_type": "image", "volume_size": "{{ from machine root-disk constraint }}", "destination_type": "volume", "delete_on_termination": true, "tag": "disk1", "disk_bus": "scsi"}]
where uuid = source image id
I think you could cover 90% of use cases with:
juju deploy cs:ubuntu --constraints="root-storage=volume root-disk=20G root-disk-autodelete=true/false"
The other properties in block_device_mapping_v2 shouldn't need surfacing back to the juju user.
upvote for this from me - although our use case is slightly different; we need volume backed disks so that we can do backups from Cinder and also dynamic volume resize. So our block would look like this:
"block_ device_ mapping_ v2": [{ c95a-448f- 9292-73986c7909 11", n_type" : "volume", on_termination" : true,
"boot_index": "0",
"uuid": "ac408821-
"source_type": "image",
"volume_size": "{{ from machine root-disk constraint }}",
"destinatio
"delete_
"tag": "disk1",
"disk_bus": "scsi"}]
where uuid = source image id
I think you could cover 90% of use cases with:
juju deploy cs:ubuntu --constraints= "root-storage= volume root-disk=20G root-disk- autodelete= true/false"
The other properties in block_device_ mapping_ v2 shouldn't need surfacing back to the juju user.