[00:17] <smoser> hey. harlowja 
[00:18] <harlowja> hey yo
[00:20] <harlowja> when u want to go over https://openstacksummitmay2015vancouver.sched.org/event/b52d0c99f65d7713c61524b5a380812b
[00:20] <harlowja> with vice executives
[00:21] <smoser> supyeah.
[00:21] <smoser> i do.
[00:21] <smoser> i had on my todo to bother you about tha ttoday
[00:22] <smoser> thank yo ufor beating me to it.
[00:22] <smoser> can we pick a time in my normal working hours tomorrow ?
[00:22] <smoser> :)
[14:07] <arnaud_orange> hi guys
[14:07] <arnaud_orange> does anyone know which cloud-init configuration I should use to disable pollinate to seed random ?
[14:17] <smoser> arnaud_orange, 
[14:17] <smoser> # pollinate hangs without socket timeout if it can't reach network
[14:17] <smoser> random_seed:
[14:17] <smoser>    command: null
[14:17] <smoser> will do it.
[14:17] <smoser> you can make 'command' anything you want.  null is yaml's "None"
[14:17] <arnaud_orange> oh nice
[14:17] <arnaud_orange> let me try that
[14:17] <smoser> but you can make it [/bin/sh, -c, 'echo hi mom']
[14:21] <arnaud_orange> Is there anything else to disable when my VM does not have access to internet, because cloud-init is taking very much time to bring my VM up 
[14:22] <arnaud_orange> it's far better with your random_seed configuration, thanks smoser
[14:22] <arnaud_orange> but still taken 178sec to be up
[14:23] <smoser> what datasourc e?
[14:23] <arnaud_orange> openstack metadata
[14:23] <smoser> are you able to pastebin a /var/log/cloud-init.log ?
[14:25] <arnaud_orange> smoser: http://paste.ubuntu.com/11096632/
[14:30] <smoser> arnaud_orange, it would appear you lose almost 2 minutes between lines 186 and 187.
[14:31] <arnaud_orange> yep
[14:32] <smoser> i would suggest disabling DataSourceGCE in /etc/cloud/cloud.cfg.d/90_dpkg.cfg
[14:32] <arnaud_orange> I think this is because the VM is not able to access http://metadata.google.internal./computeMetadata/v1/ is not resolvable
[14:32] <smoser> right.
[14:32] <arnaud_orange> what is that?
[14:33] <smoser> inside the image you have to change that.
[14:33] <arnaud_orange> GCE=GoogleCloudengine, right?
[14:33] <smoser> right.
[14:33] <smoser> remove GCE there.
[14:33] <smoser> please file a bug, as such a hang is not intended.
[14:33] <arnaud_orange> ok, if I do that, I won't be able to rely on the classic ubuntu cloud image
[14:34] <smoser> yeah, that sucks. :-(
[14:34] <smoser> file a bug, we can fix it.
[14:34] <arnaud_orange> yep
[14:34] <smoser> and SRU and then you can be happy again.
[14:34] <arnaud_orange> no way to fix it with yaml cloud-config?
[14:34] <smoser> no. 
[14:35] <smoser> as this is config that is read before we can get to user-data
[14:35] <smoser> ie, it tells us how to find user-data. :)
[14:35] <arnaud_orange> understand
[14:35] <smoser> you could try to see why dns resolution would time out on that.
[14:35] <smoser> that does seem broken that a dns resolve would block for 120 seconds
[14:35] <smoser> the only networking provided at that point is from the dhcp server
[14:36] <smoser> so your dhcp server is possibly giving a dns server that is not reachable.
[14:36] <arnaud_orange> the dns server configured on the vm is 8.8.8.8 (google)
[14:36] <arnaud_orange> but the VM does not have access to internet
[14:38] <smoser> well, that'd seem like a misconfiguration :)
[14:38] <smoser> why is it 8.8.8.8 ?
[14:38] <arnaud_orange> this is configured on my tenant network
[14:39] <arnaud_orange> because, when I set a floating IP to my VM, the VM can access internet
[14:39] <arnaud_orange> but the floating IP is not set on startup
[14:39] <arnaud_orange> it's floating between VM 
[14:39] <arnaud_orange> don't know if I am clear on that
[14:41] <smoser> right. but it seems like your network is busted still.
[14:42] <smoser> why give someone a dns server that they cannot reach
[14:42] <smoser> i guess so that later when they get a floating ip they can.
[14:42] <arnaud_orange> don't know, ask my cloud provider :p
[14:42] <smoser> who is cloud provider ?
[14:42] <arnaud_orange> cloudwatt
[14:42] <arnaud_orange> french company
[14:42] <arnaud_orange> but I think it might be the same on any openstack based cloud provider
[14:43] <smoser> no
[14:43] <smoser> thats definitely their configuration. and they could definitely give you access to a dns server internally that would dtrt.
[14:43] <smoser> i'd bug them about it. 
[15:02] <arnaud_orange> the thing is that I only want my virtual machine to have access to other machines in the tenant, without access to the internet, so not having access a an external DNS is expected
[15:05] <smoser> i'd file a bug with them.
[15:06] <smoser> a.) telling you dns is 8.8.8.8 is hacky at best (rather than a dns server they run)
[15:06] <smoser> b.) telling you a dns server is <ANYTHING> that you can't get to is kind of silly/broken
[15:14] <arnaud_orange> ok, I found a way to remove the 8.8.8.8, so a) is not an issue anymore, 
[15:14] <arnaud_orange> they provide their own nameserver
[15:14] <arnaud_orange> but, again, my tenant router have only one interface, in the private network
[15:14] <arnaud_orange> so without floating IP, no internet access
[15:15] <arnaud_orange> there is no way to disable every internet request from cloud-init point of view?
[15:15] <arnaud_orange> without modifying the ubuntu image,
[15:15] <arnaud_orange> ?
[15:28] <smoser> well, nto really.
[15:28] <smoser> but if you have dns configured correctly, then the dns should fial
[15:28] <smoser> and it will move on
[15:28] <smoser> quickly
[15:29] <arnaud_orange> you're right
[17:08] <devicenull> 2015-05-12 17:06:07,091 - util.py[WARNING]: Failed to create user foobar
[17:09] <devicenull> would be nice to know why :(
[17:10] <devicenull> oh, I guess adduser failed for some reason
[17:11] <smoser> devicenull, /var/log/cloud-init-output.log maybe
[17:11] <devicenull> yea, that's where I got that error message
[17:12] <smoser> not cloud-init.log
[17:12] <smoser> cloud-init-output.log
[17:12] <devicenull> # less /var/log/cloud-init-output.log
[17:12] <devicenull> yes, that's where that message was!
[17:14] <smoser> well thats not right. 
[17:14] <devicenull> turns out it didn't like the 'primary-group' setting I had
[17:14] <devicenull> when the primary-group didn't exist
[17:14] <smoser> log should not be going to -output.log
[17:15] <smoser> oh wait.
[17:15] <smoser> or i guess *its* output, and on warn, it wrote that to stdout