[05:44] Hi , I have some doubts on using cloud-init without a cloud platform like openstack with a kvm hypervisor on ubuntu 14.04 machine ? Where should I post it ? [05:48] http://blog.oddbit.com/2015/03/10/booting-cloud-images-with-libvirt/ : In this link the " virt-install -n example -r 512 -w network=default \ --disk vol=default/fedora-21-cloud.qcow2 --import \ --disk path=config.iso,device=cdrom " command did not work for me . [05:48] the command that I tried virt-install -n cld_int -r 512 -w network=default --disk vol=/home/aditya/scienaptic/Fedora-Atomic-25-20170106.0.x86_64.qcow2 --import --disk path=config.iso,device=cdrom gave this error : ERROR Error with storage parameters: Couldn't lookup volume object: Storage pool not found: no storage pool with matching name '' === shardy is now known as shardy_lunch === shardy_lunch is now known as shardy === rangerpbzzzz is now known as rangerpb [14:45] hello [14:46] if i specify datasource_list: [ NoCloud, None ] and don't have any seedfrom or fs_label [14:46] where will cloud init try to get user- & metadata? [14:47] will it look at /user-data /meta-data? [14:50] or hmm [14:51] is it possible for cloud init to use user-data and meta-data from local filesystem? [14:54] perhaps i can just create the a file with meta-data and user-data in /etc/cloud/cloud.cfg.d? [14:57] Raboo: NoCloud will look for either a directory in the image (/var/lib/cloud/seed/nocloud-net/{user-data,meta-data} or if you have an ISO attached with the label 'cidata' ; [14:58] Raboo: on ubuntu, the 'cloud-image-utils' package provides a tool, 'cloud-localds' which helps create such an iso and shows how to attach to a local kvm instance [14:59] rharper i'm thinking baremetal, not kvm [14:59] either works [14:59] ok [15:00] rharper i also just realized i can just put the user-data and meta-data in /etc/cloud/cloud.cfg.d i think. [15:00] some config can be set there; I suggest populating /var/lib/cloud/seed/nocloud-net/ [15:01] you can put user-data and meta-data in /etc/cloud/cloud.cfg.d/ also [15:01] the NoCloud's datasource config allows you to just put it there. [15:01] cool [15:02] rharper i built an image with openstack's disk-image-create: [15:02] DIB_CLOUD_INIT_DATASOURCES=NoCloud disk-image-create ubuntu baremetal dhcp-all-interfaces -o my-image [15:03] and the qcow2 image didn't have a /var/lib/cloud folder [15:04] you have to populate that; you can use mount-image-callback from the cloud-image-tools to mount up and modify; or as smoser suggested, you can put the config in /etc/cloud/cloud.cfg.d/ if that dir is already there [15:04] mkdir -p /var/lib/cloud/seed/nocloud-net etc. [15:05] or cloud-localds also [15:05] withoutput tar [15:06] ok [15:06] why is there 3 different hostname in meta-data? [15:07] ? [15:07] hostname, local-hostname, public-hostname [15:07] and which one do i need? [15:08] my previos experience i didn't need to build a meta-data file. but that was with kvm and opennebula, most likely openneubla already took care of that. [15:08] you dont need any. [15:08] i am confused. [15:08] if you're building a bare metal image for openstack [15:08] no, for on-premise [15:08] then when you deploy it with openstack, openstack should deal with providing meta-ata [15:09] i don't have openstack. [15:09] i'm using foreman and trying to build a image deploy function for it. [15:10] is meta-data needed? [15:10] the easiest thing to do would probably be just to disable cloud-init . by removing it, or (if newe enough cloud-init) touch /etc/cloud/cloud-init.disabled [15:10] but i want cloud-init to configure the machine first boot. [15:10] set hostname, install chef, run chef.. [15:11] the user-data contains hostname and fqdn. So i'm wondering if i need meta-data also. [15:12] https://github.com/number5/cloud-init/blob/master/doc/examples/cloud-config-datasources.txt#L28 [15:13] Raboo: AFAIK, you only need an instance-id: XXXX in meta-data [15:13] rharper ok [15:17] taken our discussions, this is what i ended up with: http://pastebin.com/PmRcY7hK [15:18] rharper, smoser thanks for the input. [15:18] Raboo, but how will you give it user-data ? [15:19] looks like writing out to cloud.cfg.d/ [15:19] are you planning on writing user-data to the image and then deploying it? [15:19] my plan is this: [15:19] 1. unknown node boots via pxe and loads a discovery image. [15:20] 2. node pops up in foreman, and i press provision. [15:21] 3. node reboots with a small image the runs a bash script that curls |dd of=/dev/sda [15:22] 3b. the small image mounts /dev/sda to /mnt, writes /mnt/etc/cloud/cloud.cfg.d/[that file from pastebin, but rendered with hostname..] [15:22] 3c. reboot [15:23] 4. node boots from hdd and runs cloud init to configure the machine and run chef. [15:25] Raboo, generally speaking that should work. [15:32] Raboo, does foreman provide any way to provide user-data ? [15:32] without the ability for the user to provide some customizaiton information themselves, you kind of are very limited. [15:40] smoser foreman has so called Provisioning tempaltes, intended for preseed, kickstart etc etc.. [15:41] basically you can have a dynamic cloud-init file as a provisioning template. [15:41] so how would that tie in here. [15:41] hmm. ok. [15:44] smoser: magicalChicken: were either of your looking to bring in a curtin.net module update to cloudinit.net ? [15:47] so my step 3 basically a small linux image that writes the ubuntu os image to disk and then downloads the cloud-init provisioning template from foreman and puts it in /etc/cloud/cloud.cfg.d/99-magicstuff. [15:48] Raboo, how does the small linux image get booted ? [15:48] just curious. is it initramfs ? [15:50] smoser yea, via pxe, will use this image https://theforeman.org/plugins/foreman_discovery/8.0/index.html#2.3ForemanDiscoveryImage [15:50] will dual purpose it. [15:51] discovery and deploy [16:07] will cloud-init know that it is initialized (or will it try to run /etc/cloud/cloud.cfg.d/99-magicstuff every boot)? [16:13] Raboo, well, you have an instance-id in that. [16:14] if the instance-id changes, it will do the per-instance things again [16:18] rharper: yes [16:18] I was planning on working to combine the two modules into one code base [16:19] I am still writing a doc for that, I'll send it out this weekend [16:26] ok === rangerpb is now known as rangerpbzzzz