=== harlowja is now known as harlowja_away [15:17] lotia, yes, you can do that or give user-data to do it. [15:17] ie, something that isn't well understood / known is that cloud-config provided by userdata == cloud-init configuration files in /etc/cloud/cloud.cfg.d/ === harlowja_away is now known as harlowja === medberry is now known as med_ [21:10] harlowja: I read yahoo switching to https on e-mail, probably related :) [21:43] harmw i think so :-P [21:46] HI all, my ssh key does not seam to get imported from openstack when cloud-init runs. How would I debug this? [21:47] alevy which datasource are u using with openstack? [21:48] config drive? [21:48] other? [21:48] what version of cloud-init [21:51] harlowja: im not sure what data source, how do I check? 0.7.3 [21:52] cloudinit will tell you which sources it tried [21:52] do u know how the openstack u are using is setup? [21:52] that will affect which datasource cloud-init should try [21:52] but as harmw said, the console log of openstack should also tell u what was being tried [21:53] you didn't forget to pass --key mykeyname on booting the instance alevy :) [21:53] and if not /var/log/cloud-init.log usually has more [21:53] harmw: started it from the console [21:54] harlowja: it is a nebula one openstack cloud [21:54] one image is working the other isn't... [21:54] nova boot --flavor bla [..] --key-name thisismykey [21:54] ah [21:54] alevy hmmm, then it could vary, do u know what the nebular people recommend for images? [21:54] alevy, you can check to see if your key is there in 'ec2metadata' [21:54] is that image known to work (that they are providing) [21:54] which image works, which one doesn't? [21:54] the one someone downloaded but I am trying to build my own (for certain rrsons) [21:55] i think nebula use ubuntu cloud images (even pull them in by default) [21:55] both centos 6.4 with the same cloud-init package installed and same config [21:56] alevy build your own, hmmm [21:56] Can i run it interactively to see what is happening, I dont understand what is in the logs... [21:56] alevy is it possible for u to pastebin the logs somewhere (filter out anything u don't want to show?) [21:56] smoser: how do I check that [21:56] harlowj: sure [21:58] alevy, in ubuntu you'd have a package 'ec2metadata' [21:58] just run it and it will crawl the metadata [21:58] from inside the system (assuming you got in, but you clearly might not bee able to) [22:01] smoser: bash: ec2metadata: command not found [22:01] smoser: centos [22:01] ah. well then [22:02] logs at /var/log/cloud-init.log should be useful here [22:02] *if any [22:02] $ curl -q http://169.254.169.254/latest/meta-data/public-keys; echo [22:02] 0=brickies [22:03] curl -q http://169.254.169.254/latest/meta-data/public-keys; [22:03] 0=alevy [22:03] looks ok there... [22:07] does cloud-init care about selinux? [22:09] define 'care'? [22:11] it should handle it. [22:11] i have to run [22:11] later. [22:16] harlowja: i noticed one image has it enabled and the other doesn't, just looking for differences... [22:17] kk, can u also check the diff between the cloud.cfg files @ /etc/cloud/cloud.cfg [22:17] a diff there might be part of the issue [22:18] harlowja: nothing commented out matters right? [22:18] right [22:19] ok they are identical then [22:19] hmmm, k, thats pretty odd [22:20] harlowja: is there a way to run cloud-init and see if it is puking or something? [22:20] ya, u can run cloud-init just via $ cloud-init [22:20] do indents matter? [22:20] i.e. "-" vs. " -" [22:21] potentially [22:21] yaml is white space sensitive [22:21] gr [22:21] ok i see what may be the problem then [22:21] kk [22:27] yaml is valid and nothing changed when I re-ran cloud-init [22:31] valid yaml could still mean the yaml isn't right, if the spacing is right thats usually valid, but it might still be off [22:31] u should be able to run $ cloud-init single 'module-name' [22:31] and then see if one is dying [22:31] perhaps run just the ssh one [22:33] harlowja: cloud-init single --name ssh ? [22:34] i think so [22:35] cloud-init single --name 'ssh' --frequency once [22:35] that did something... [22:36] generated public private keypair [22:36] how do I test the fetch of keys from openstack? [22:37] so i think u should be able to run $ cloud-init init [22:37] and that will rerun the fetching part [22:37] does not seem to [22:38] any output at all? [22:38] just prints out the networking stuffs [22:38] k, its probably noticing u already fetched the data [22:38] can u check /var/lib/cloud/ [22:38] if u temporarily move that directory to somewhere else, it should re-run [22:39] that directory is where cloud-init stores alot of its data [22:39] especially under /var/lib/cloud/instance [22:40] ok moved it and now it prints the networking and generates the keys again but says Failed to generate ecdsa key [22:41] ok, afaik rhel has issues with the ecdsa key, but the rest of the keys should be getting made, [22:41] the question i guess is did it put your keys in place [22:41] maybe try the cloud-init single --name ssh again [22:42] it makes the ones in /etcssh/ for sure i just checked the fingerprint [22:43] k [22:43] is the ssh module the one that fetches the key from openstack? [22:44] http://cloudinit.readthedocs.org/en/latest/topics/modules.html [22:44] that is totally empty.. ha ha [22:45] hmmm, ya, thought that had some data in it [22:45] the modules are @ http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/cloudinit/config/ [22:48] https://gist.github.com/8326025 [22:48] that is the log btw, gist came back up [22:48] ah, k [22:50] hmmm, ya, its using 'iid-datasource-none' which confuses me [22:51] what does that mean? [22:51] its supposed to find the ec2 one [22:51] datasources provide where cloudinit gets info from, ec2 being one [22:51] the none one is like a fallback [22:53] do i need to set that in cloud.cfg? [22:53] let me paste that too [22:53] https://gist.github.com/8326105 [22:54] u can, it might help reduce the set of ones it will try [22:54] adding the following will help reduce the options [22:54] # Only these datasources will be attempted (in order) [22:54] datasource_list: [22:54] - ConfigDrive [22:54] - Ec2 [22:54] - None [22:54] or something like that [22:55] u are running the '- disable-ec2-metadata' module though [22:55] that alters iptables, so that means u can't probably run cloud-init twice [22:55] without unblocking that iptables filter [22:55] probably for testing disable that module running [22:59] ok i disabled that module [22:59] and ran again [22:59] still not fetching any keys [23:00] https://gist.github.com/8326270 [23:00] https://gist.github.com/8326272 [23:01] did u make a new instance? or the same one? [23:01] same one. should I make a new one? [23:02] ya, if that module already ran, it turned on an iptables rule that stops the metdata from being fetched [23:02] can i just flush iptables? [23:03] probably [23:04] seems to still be using None [23:05] ok I have to run [23:05] i guess i just need to keep looking? [23:06] ya, make sure u are removing /varl/lib/cloud each time u try to re-run [23:06] i'd restrict what datasources are allowed to [23:06] to avoid all these other ones being activated [23:07] ok