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… | |||||
ardumontAuthorUnsubmitted 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)