[01:36] <blackboxsw> thx smoser I'm reworking ifconfig-drop branch to incorporate more review comments, it'll be tomorrow before it's ready
[16:42] <blackboxsw> just found a bug in the dropping ifconfig/route branch on devices which don't have addresses (like deactivated wirelesss interfaces).
[16:42] <blackboxsw> tweaking the logic and also attempting a regex approach instead of this separate for loop nonsense to see if it's faster
[16:43] <blackboxsw> s/separate/decoupled/
[18:57] <smoser> blackboxsw: help ?
[18:57] <smoser> http://paste.ubuntu.com/p/sWZg7wbPNH/
[18:58] <blackboxsw> checking. /me is neck deep in regex atm
[19:00] <dpb1> blackboxsw: don't die
[19:01] <blackboxsw> so python only imports a module once right, once the mock is active it would apply to the global wouldn't it until the mock is released.
[19:01] <nacc> smoser: are cloudint.util and cloudint.ssh_util.util the same thing?
[19:01]  * blackboxsw checks to be sure
[19:01] <blackboxsw> yeah they are the same
[19:01] <nacc> i think this a case where yhou need to mock the local util.write_file
[19:01] <nacc> not the one in the class
[19:01] <nacc> because it's already been imported at this point
[19:02] <nacc> https://docs.python.org/3/library/unittest.mock.html#id5 the bit about mocking where something is used
[19:02] <nacc> and importing puts things in the local namespace, not the source namespace (iirc)
[19:02] <nacc> it's different if you do a from ... import too
[19:06] <smoser> blackboxsw: yeah, they're the same thing. and yeah nacc is right i'm sure, bu t i just should have somehow known this before. i'm sure we do stuff like this otherplaces in tests.
[19:06] <smoser> but oh well
[19:06] <nacc> smoser: i ran into this while writing some of our tests for git-ubuntu
[19:07] <nacc> smoser: if you had just run 'import cloudinit', i believe your code would dtrt
[19:07] <nacc> smoser: but since you import a specific module from cloudinit, it 'imports' it into the current modules' namespace
[19:08] <nacc> so there's now a testme.util which is what you actually want to mock, i think
[19:08] <nacc> (or so, there are some examples i've found in the past for what you are supposed to use for hte module/class name)
[19:08] <nacc> i can keep the logic in my head for about 1 minute and then it slips away again :)
[19:09] <nacc> smoser: the frustrating part is, it also depends on how the tests run -- so sometimes things work when they really probably shouldn't (or you end up getting one test affecting all other tests in the same class/test file)
[23:05] <seba> heyja
[23:09] <seba> I'm currently playing around with the cloud init user_data config
[23:09] <seba> I'm wondering... if the image I want to configure with cloud-init has a lot of stuff configured in its /etc/cloud/cloud.cfg (a debian in this case) how can I override these defaults?
[23:10] <seba> the debian default cloud.cfg adds a default "debian" user. I don't want that, but it seems to be specified there and it gets added even if i specify my own users in my user_data