[01:12] smoser: in your example, was there a reason you did your symlink as relitive? [01:14] smoser: also, I added comments in my gentoo net fix that shouldn't be there (but aren't harming anything) === sterfield_ is now known as sterfield [11:08] hello, I'm trying to launch a fedora.qcow2 cloud image with qemu-kvm locally, by mounting the meta-data and user-data files on the cd-rom, but sometimes it doesn't respect those settings, any idea why this might be? Can someone point me to how should begin debugging this? [11:31] prometheanfire, it is at least generally prerred in debian for symlinks to be relative. they're easier to work with for sure. [11:32] even in the test, the goal is to "render" stuff all into a target root, and easier to read content from that directory if it doesnt leak outside. [11:32] ffledgling, it fails sometimes ? [12:06] smoser: yes, it fails sometimes. When I clean everything up and start it from scratch, it works fine, but if I restart the instance it fails [12:06] I'm using the no-cloud plugin I think with the user-data and meta-data file [12:06] I suspect it might be because of "Note: that the instance-id provided (iid-local01 above) is what is used to determine if this is “first boot”. So if you are making updates to user-data you will also have to change that, or start the disk fresh." [12:06] But I don't quite get what that means [12:07] ffledgling, 2 things coudl be happening [12:07] a.) if you want the system to re-run initialization "first boot", then you will have to provide a new instance-id [12:08] cloud-init only runs '#!' scripts and much other user-data bits on first instance boot [12:08] so it determines 'first instance boot' by seeing the instance id and comparing it to one it stored from the last time. [12:08] so if you boot once with instance-id of 'abc' and then change the user-data and boot again with 'abc' it wont pick it up. [12:09] Okay, I'm not doing that, and I don't think I want/need to. The default behaviour seems to be what I want [12:09] b.) it could be a race condition where the nocloud disk isn't there yet at the point in which cloud-init runs. [12:09] i've not seen this in practice, but it is plausible. [12:09] oh [12:09] That would make sense [12:10] if you think this is happening, please [12:10] I don't know if it is, how would I confirm? [12:11] - change logging to go to a file only [12:11] see https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729 for how to do that. [12:11] (basically change /etc/cloud/cloud.cfg.d/05_logging.cfg as show) [12:11] - boot the system [12:11] - shut the system down [12:11] - collect /var/log/cloud-init.log [12:11] you dont have to shut down if you dont want, if you can log in feel free to get it that way. [12:12] i have to go afk for a bit. [12:12] back later. [12:12] Okay, I can't actually login to the box at all, so I'm not sure I can modify any of the cloud.cfg file? [12:12] I'm using cloud-init to provide a password to the instance. === rtheis_ is now known as rtheis [13:19] ffledgling, mount the image and change it before booting. [13:19] you can use mount-image-callback or guestfish or something. http://ubuntu-smoser.blogspot.com/2014/08/mount-image-callback-easily-modify.html [13:20] smoser: do I have to use the returned object? 'ns = parse_net_config_data(netconfig)' or can I use the json directly? [13:25] prometheanfire, well, i'd like a Renderer and the Renderer takes network state. [13:25] i'd like it to be have like the others, so that as we modify / improve things, we wont have snowflakes [13:26] smoser: it just seems like a lot of work for rendering something so simple [13:34] smoser: http://dpaste.com/2V9JTX3 here's the full log which I obtained after adding the change you suggested yesterday to the logging config. Looks like ssh-authkey-fingerprints is running before cloud-user gets created (even though the logs seem to suggest cloud-user was created first?) [13:39] prometheanfire, fyi my comment https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init/+merge/303471/comments/784454 applies to you also [13:39] i assume you probably followed the HACKING ;) [13:40] actually, no. it i think says it right. [13:42] smoser: smoser this is an example of doing it all (bridge bond phys vlan) https://gist.github.com/prometheanfire/d1eb9d60fecf25ac7418c8f4160201b3 [13:43] it allows access to a vlan trunk [13:44] smoser: ? [13:44] what about that comment? [13:45] you ust that you can use a shorter remote [13:45] I have three origins for my cloud-init repo [13:45] you have git.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init [13:45] you can do [13:45] you have git.launchpad.net/~prometheanfire/cloud-init [13:46] well, the remote's already set up [13:46] prometheanfire@git.launchpad.net:~prometheanfire/cloud-init [13:46] that's how it's already set up [13:47] prometheanfire, right. the only value in it is then i can more easily do things like: [13:47] for user in prometheanfire utlemming; do git remote add $user git.launchpad.net/~prometheanfire/cloud-init; done [13:47] well, probalby should use '$user' in the url, but i thjink you get the idea [13:48] i did that yesterday, and couldn't figure out why getting your remote was failing [13:48] ya [13:48] not sure why it was failing [13:49] given it seems it's set up right [13:51] shoot. [13:51] i typoed in that comment [13:51] smoser: do you mean the iso or the actual fedora image? [13:51] that is what is confusable [13:52] ffledgling, the image [13:57] smoser: anyway, soooooooooooooooooo much boilerplate [13:58] prometheanfire, i know... let me see. [13:59] cleaned up hopefully more obvious comment now [13:59] sorry [13:59] https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init/+merge/303471/comments/784467 [13:59] I'm just not used to dealing with this much indirection and flow and functions that don't really do aything useful [14:00] smoser: so you need me to do something? [14:05] prometheanfire, if you can push to the shorter version, it'd be nice. its just more consistent. but if not , oh well. [14:06] wrt the indirection, let me see if there is some sane way to use that for you. [14:06] thanks [14:06] this is java like python from what I can see :P [14:10] smoser: guess that's what you wanted (push wise) [14:14] prometheanfire, yeah, its all there to try to make things easier. :-( [14:14] take a look at eni.py and see if that is any easier for you to wor off of than sysconfig.py. [14:15] the network state thing doesn't really provide a lot. [14:15] ya [14:15] the interfaces are just like the network-config object that went in... you can iter_interfaces() [14:15] I'll take another look tomorrow [14:15] today is really full [14:15] and iter_routes() [14:16] it shouldnt' be really too much more difficult to use that than to walk through the network_config object [14:17] ya, it's more how they construct each network stansa that is hard [14:17] no string formating :P [14:18] I'll see what I can do I guess [14:18] tomorrow [14:28] prometheanfire, thank you === gfidente is now known as gfidente|afk [20:08] prometheanfire yes its not optimal ;) [20:08] i did a first stab at making it better, prometheanfire any more u want to do is welcome :) [20:08] (and yes its confusing as all-hell, lol) [20:08] ya [20:09] 3 different layers of translation and processing [20:09] for not really sure why, ha [20:09] yep