=== harlowja is now known as harlowja_away [13:42] guys, where's the .py file that plays with networking configuration, especially, /etc/network/interfaces ? [13:47] ok, this is handled in distro classes [14:18] it looks like cloud-init writes to /etc/network/interfaces from a template where eth0 is not marked as auto. a) can I tell cloud-init to not alter /etc/network/interfaces ? or b) where can I modify the template, if any? [14:20] I have put eth0 configuration into /etc/network/interfaces.d/eth0 and would like cloud-init to not overwrite /etc/network/interfaces unless I put some configuration directive in my meta-data file [14:39] jseun: are you booting with a config drive? Or just using the metadata service? With a cursory glance at the source, it looks as if cloud-init only ever writes that file when using config drive, nocloud, or OpenNebula data sources. [14:39] ...but I could be wrong. [14:40] larsks: it's meta-data and user-data file written to an ISO, I guess this is NoCloud [14:40] No, that's config drive :) [14:40] ah! :) [14:41] Huh, it *looks* as if the network configuration is only written if your metadata includes network configuraiton information. I'm looking in cloudinit/sources/DataSourceConfigDrive.py, around line 215. [14:41] Similarly, in .../DataSourceNoCloud.py around line 186. [14:42] I'm actually not sure which data source you're hitting :/ [14:42] larsks: my meta-data file does not specify any network configuration, yet /etc/network/interfaces got smashed [14:43] Hmmm, in the nocloud datasource, there is also a check against (self.dsmode in ("local", seeded_interfaces)), and I don't know the code well enough to know what that does. [14:43] I guess I would stick some debugging code in there and run it from the command line to see what happens. [14:44] I fixed it, for now, having auto eth0\niface eth0 inet dhcp\n in the meta-data file [14:44] that is config drive' [14:44] meta-data and user-data. [14:45] cloud-init in 0.7.X really expects that eth0 is 'auto' in the OS. [14:45] Weird, then, because it looks like the network config is only written if there is a network_config key available. [14:46] networking is one thing that really needs improving. [14:46] it is complex though, to block system boot waiting for networking information from somewhere that might not be there... [14:46] at least for making generic images, and the goal for ubuntu is "one image that works everywhere". [15:04] any ways I could provide the eth0 ip address in final_message or is it more a runcmd thing? === rcj is now known as Guest25083 [21:36] hi.... How can you determine what cloud-init thinks is the default user? [21:38] That is, how can I be sure my "default_user" parm in /etc/cloud/cloud.cfg worked? [22:01] http://paste.ubuntu.com/10164529/ [22:02] harlowja, arent we missing the return on the not case tehre? [22:02] surely would seem like it, lol [22:02] good catch [22:03] smoser: Does my above query make any sense? [22:04] tennis, /var/log/cloud-init.log has a line like: [22:04] 2015-02-10 21:37:24,737 - __init__.py[INFO]: User ubuntu already exists, skipping. [22:04] smoser: ah, ok. Thanks! [22:14] harlowja, lp:~smoser/cloud-init/py2-3 we're closer. [22:14] woot [22:15] progress [22:15] i'm down to a failure around random_seed. [22:15] i really hate bytes and strings and encode and decode [22:15] :) [22:15] ya [22:15] me too [22:15] waste of my life, lol [22:17] alright. [22:17] i hope to upload to vivid tonight. [22:17] later. [22:22] cool [22:22] lata