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