Changeset View
Changeset View
Standalone View
Standalone View
proxmox/terraform/storage.tf
- This file was added.
# Keyword use: | |||||
# - provider: Define the provider(s) | |||||
# - data: Retrieve data information to be used within the file | |||||
# - resource: Define resource and create/update | |||||
provider "proxmox" { | |||||
pm_tls_insecure = true | |||||
pm_api_url = "https://orsay.internal.softwareheritage.org:8006/api2/json" | |||||
# source ./setup.sh | |||||
} | |||||
resource "proxmox_vm_qemu" "storage0" { | |||||
name = "swh-storage0" | |||||
ardumont: Right now, the name is different (should be uffizi) because:
- we need it to define the… | |||||
Done Inline Actions(I submitted anyway because i wanted to keep my reasoning somewhere) My fear seems unfounded as per [1] From what i gather, the composition of the {vm-name, target-node} are used to refuse to create 2 similar named vm (aside the case of using forceCreate flag which we won't use, so i say ;) (target-node being the hypervisor) Still, i prefer to stay on the safe side for now. ardumont: (I submitted anyway because i wanted to keep my reasoning somewhere)
My fear seems unfounded… | |||||
desc = "swh storage node" | |||||
# hypervisor onto which make the vm | |||||
target_node = "orsay" | |||||
# See init-clone.org to see the bootstrap of the template vm | |||||
clone = "template-debian-10" | |||||
# linux kernel 2.6 | |||||
qemu_os = "l26" | |||||
# generic setup | |||||
cores = 1 | |||||
sockets = 2 | |||||
memory = 4096 | |||||
onboot = true | |||||
#### cloud-init setup | |||||
# to actually set some information per os_type (values: ubuntu, centos, cloud-init) | |||||
os_type = "cloud-init" | |||||
# ciuser - User name to change ssh keys and password for instead of the image’s configured default user. | |||||
ciuser = "root" | |||||
# cipassword - Password to assign the user. | |||||
cipassword = "test" # for testing, do not commit this | |||||
Done Inline ActionsThat will go away at some point (prior to landing). ardumont: That will go away at some point (prior to landing). | |||||
# searchdomain - Sets DNS search domains for a container. | |||||
searchdomain = "internal.staging.swh.network" | |||||
# nameserver - Sets DNS server IP address for a container. | |||||
nameserver = "192.168.100.29" | |||||
# sshkeys - public ssh keys, one per line | |||||
sshkeys = "${var.ssh_key_data}" | |||||
# ipconfig0 - [gw=] [,gw6=] [,ip=<IPv4Format/CIDR>] [,ip6=<IPv6Format/CIDR>] | |||||
ipconfig0 = "ip=192.168.100.125/24,gw=192.168.100.1" | |||||
ssh_user = "${var.user_admin}" | |||||
disk { | |||||
id = 0 | |||||
type = "virtio" | |||||
storage = "orsay-ssd-2018" | |||||
storage_type = "ssd" | |||||
size = "32G" | |||||
} | |||||
network { | |||||
id = 0 | |||||
model = "virtio" | |||||
bridge = "vmbr0" | |||||
} | |||||
} | |||||
Done Inline Actions--noop should go away as we want to actually apply. --certname might be best to not use it (but i don't know why yet ;) ardumont: `--noop` should go away as we want to actually apply.
That means that we must know already what… |
Right now, the name is different (should be uffizi) because:
I'd prefer we use "vm id" but as far as i could tell, we cannot for now.
So to be on the safe side, i'll continue with different names for now.
[1] ftigeot spoke about dhcp but i'm unsure of the delay implied by this solution (which i think would possibly the right one in the long run)