=== harlowja_ is now known as harlowja_away [10:47] Hello guys [10:47] what is the best way to add my elastic ip in /etc/hosts with cloud-init please [10:58] ? [13:05] HanSolo, theres nothing that can do thta for you. :-( [13:42] smoser: Thanks for the merge yesterday. :) [13:43] smoser: Here's another little one: https://code.launchpad.net/~daniel-thewatkins/cloud-init/lp-1311463/+merge/253362 :) [13:43] Odd_Bloke, ok. thank yo ufor writing tests. [13:45] :) [14:38] smoser: I have to use this (ugly) kind of workaround then ? http://ternarylabs.com/2010/09/15/automatically-configure-hostname-for-new-ec2-instances/ [14:39] I know this is beyond scope of cloud-init sorry for asking :/ [14:39] HanSolo, its not really beyond the scope. [14:39] i'd like to have a solution for you [14:41] thank you smoser, this is still a great product === harlowja_away is now known as harlowja_ [17:59] harlowja_: ever seen this with kvm? https://bugzilla.redhat.com/show_bug.cgi?id=1202990 [18:00] harmw don't think i've seen that [18:00] but we don't run on fedora, so thats maybe why [18:00] ah, well, CentOS 7 showed the same [18:01] ah [18:01] haven't seen that [18:01] are you aware of certain ovs specifics one should be setting? [18:01] not off the top of my head [18:01] i'm using an mtu of 1400 here btw, for what its worth [18:14] harmw if u jump on #openstack-operators u may find some folks there that have some idea [18:14] oh sure, thanks [18:14] np [18:14] someone there might of seen this [18:14] I'm gonna try if I can get some results from -not- running through nova [18:14] k [18:15] eg, dropping a lot of the extra kvm parameters [18:15] ya, maybe u'll figure it out [18:30] probably not though :P [18:36] lol [19:26] Could somebody help me troubleshoot a long period on cloud-init modules:config [19:29] I run cloud-init on a centos6 image and it get's an IP address quickly but then it just sits there for a long duration before completing [19:29] http://pastebin.com/XkwiUxsN [19:29] that's what the logs show === shardy is now known as shardy_z [23:26] stupidnic, i suspect /var/log/cloud-init.log has some WARN in it. [23:26] can you paste that ? [23:27] smoser: it does not [23:27] hm.. [23:27] let me jump into that server again [23:27] its poling something. [23:27] that was my thought too [23:27] seemed like a timeout or something [23:28] cloud-init.log is zero length [23:28] I can show the entire cloud-init-output.log if you like [23:30] http://pastebin.com/gimfKReE [23:30] nothing much really [23:30] there is just that huge 500+ second delay between the ci-info output and the modules:config run [23:31] I can clone the base image and turn on more debugging, I just don't know how to do that actually [23:35] stupidnic, the log is getting swallowed somewhere. [23:35] oh.. syslog. [23:35] try looking in /var/log/syslog or wherever syslog messages would go. [23:35] grep -r "cloud" /var/log [23:36] coming up empty [23:36] well not empty empty [23:36] but nothing new [23:36] odd. well, anything important here ? [23:37] ie, do you care particularly about the instance [23:37] 2 things to try [23:37] a.) edit /etc/cloud/cloud.cfg.d/05_logging* [23:37] It's a customer instance [23:37] then yes, yes you do :) [23:37] reproduce somewhere else ? [23:37] but I can dump the base image out of glance [23:37] and then fiddle with that [23:38] and the put it back into glance and use it as a base for testing instances [23:38] oh. can you see the console log of the instance ? [23:38] nova console-log ... [23:38] Yeah it's more of the same sadly [23:38] that may have WARN on it too [23:38] the original pastebin was taking from that [23:39] well, debug messages woudl be useful. [23:40] so that 05_logging.cfg [23:40] just comment otu: [23:40] - [ *log_base, *log_syslog ] [23:40] that line. [23:40] and then it should log directly to the file [23:40] k [23:40] let me dump the image and get that taken care of [23:45] smoser: okay... what should I be commenting out here? just the stuff under log_cfgs: section? [23:46] just that line. [23:47] alright, done... let me load the image back into glance and spin up an instance [23:52] well of course... it didn't do it this time [23:52] cloud-init took 22 seconds from start to finish [23:52] do you see log too ? [23:53] yes [23:53] the cloud-init.log is over 140KB in size [23:54] About the only difference this time was the size of the instance and the tenant [23:54] client instance was 1TB this was only 10GB [23:55] possible that the size difference was the delay? [23:55] oh. well, was it the first boot ? [23:55] Yes [23:56] yeah. cloud-init resizes the disk [23:56] and on an older kernel, that is very slow. [23:56] I thought that occurred in the init ramdisk [23:56] on older kernels, it will rewrite the partition table in the ramdisk [23:56] at least in Centos 6 [23:56] right [23:57] (on newer ones it does that in cloud-init too) [23:57] yeah this is a centos 6 image [23:57] so 2.6.32 kernel [23:57] < 3.2 kernel is stupid slow resizing. [23:57] i tihnk its actually 3.10 that is , not kidding, 1000x faster. [23:58] hmmm... might be worth going with the centos lt kernels then [23:58] Something to consider. I don't want to fragment my images too much though [23:58] is not really taht simple (its hiding some of the operations i think) but, a 'resize2fs from 2G -> 1TB' will be probalby 1000x faster on nwere kernel. [23:58] last thing I need is to support five variants of each OS [23:58] yeah. i'd probalby live with it. [23:59] Let me try a larger instance and see what it does [23:59] I have SAN to burn ;) [23:59] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1179610