[08:15] smoser: I haven't looked at it, but my recollection of test_exception_fetching_fabric_data_doesnt_propagate is that data sources shouldn't raise exceptions. [08:22] Reading cloudinit.sources.find_source, that isn't true. [08:22] But I believe that was the motivation behind it. [16:13] prometheanfire, there is one question for you at https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/303339 [16:15] i'd pull that, but would ike to know why we need that change [16:15] harlowja, around ? [16:15] https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301731 [16:15] try: [16:15] from unittest import mock [16:15] except ImportError: [16:15] import mock [16:15] why do we need that ? [16:15] (we have it lots of palc). [16:16] smoser: python3 and python2 compat? [16:16] (possibly) [16:17] nacc, well, yes, but we do not do it in other places [16:17] and it works happily [16:17] or i'm oblivious to the failure :) [16:18] mgagne_, i'm going to pull bond_name [16:18] smoser: cool, it fixes all known issues described in the bug report [16:18] smoser: heh could be -- it looks like maybe unittest.mock has been backported, unclear [16:18] smoser: I couldn't find the root cause of the race condition we talked about yesterday, rebooted 20x times and no luck [16:53] rharper, around ? [16:53] given http://paste.ubuntu.com/23082413/ [16:54] should enp0s1 have 'auto' on line 253 ? [16:55] i think it probably should [17:23] smoser: here [17:24] smoser: let me compare to the curtin vlan tests [17:25] I don't think so as the vlan config will raise the underlying iface [17:27] smoser: so, if you put auto, and manual, networking-online check fails [17:27] ifquery --list --allow-auto will show the iface [17:27] but since it has a manual config, there's nothing to ifup [17:27] this will break the wait on all ifaces to be online [17:40] rharper, ok. i actually didnt' see 'inet manual' [17:40] so you think that is ok ? [17:40] it's required [17:41] vlan hooks do an up on the raw interface [17:41] before applying the vlan config [17:41] we don't want manual interfaces in the auto list or networking service fails to come up [17:41] (ie, nothing is going to "up" a manual interface) [17:41] hence the manual part [17:42] explicitly, we do not auto $IFACE on underlying devices unless they also have a network config (subnet) [17:42] the hooks for bond, vlan and bridge handle bringing up the lower interface, if needed [17:55] i don't think unittest.mock got backported [17:57] harlowja, so how does tests/unittests/test_datasource/test_configdrive.py work ? [17:57] it just does [17:57] from ..helpers import TestCase, ExitStack, mock [17:58] and 'mock' from helpers is just 'import mock' [17:59] hmmm, whats in our requirements for that [18:00] https://git.launchpad.net/cloud-init/tree/test-requirements.txt#n3 [18:00] i think we can just do import mock [18:00] it should be fine [18:00] thats more or less what the openstack folks did [18:01] because mock is maintained such that its equivalent to the py3.x one [18:01] equivalent or better [18:01] but overall yes smoser we should do some test cleanup [18:01] it needs it :-P [18:01] *its needed [18:05] harlowja, ok. [18:05] so can you [18:05] a.) just rebase that thing oncurrent tip [18:05] and then push [18:05] (no more changes necessary) [18:05] then i can merge and push and the MP will know it got pulled [18:05] b.) go ahead and fix those import mock things everywhere. [18:07] hmmmm, k [18:07] why rebase needed :-P [18:07] just wondering [18:08] usually if there aren't conflicts then rebase shouldn't be needed? [18:15] harlowja, you either have to rebase and push or i have to merge and accept the 'merge commit' [18:15] k [18:16] hmmm, intersting [18:16] its same as anywhere. [18:16] if you're full fast foward, then i can just pull and still use your commit hashes [18:16] kk [18:16] and thus the merge proposal can just magically "know" that your merge got pulled [18:16] gotcha [18:16] ok, good to know [18:17] if do 'merge' and its not a FF then i get a "merge commit" [18:17] Merge remote-tracking branch 'harlowja/space' [18:17] and i hate looking at those things :) [18:19] :-P [18:19] fair nuff [18:19] anything to make the scott happy [18:19] lol [18:23] i'll get around to that soonish [18:23] btw [18:24] harlowja, i'll take care of it. [18:25] you do 'b' instead. [18:25] thanks [18:25] lol [18:25] k [18:25] but i wanted to do a [18:25] lol [18:29] :D [19:55] Hi [19:55] I'm having some trouble to use vendor-data for setting up instances. There is any config at cloud-init that must be done for this to work? [19:55] I getting vendor-data from an OpenStack's datasource and it's been saved like this: [19:56] cat /var/lib/cloud/instances/d1a0a861-e386-444c-aea8-196e2540cfc4/vendor-data.txt [19:56] #cloud-config [19:56] package_update: true [19:56] packages: [19:56] - htop [20:41] how can I enable logging for cloud-init? smoser mentioned being interested to see the contents of /var/log/cloud-init.log if I am able to reproduce an error (and we do seem to be reproducing it) but the log file is always empty. [20:41] haven't been able to track down any docs saying how to set log levels or anything [20:41] cn28h, change logging to only go to a file. [20:42] https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729 [20:44] aha