[01:35] <smoser> blackboxsw, right.
[01:35] <smoser> it *should* be ok to do what we're doing.
[01:35] <smoser> and this path (dhcp and use that address) is actually less likely to cause any issues
[01:35] <smoser> than using the ipv4 link local path.
[01:35] <smoser> we can talk about that... maybe we don't need a fallback path.
[01:35] <smoser> have to think more
=== shardy is now known as shardy_lunch
=== shardy_lunch is now known as shardy
=== shardy is now known as shardy_mtg
=== shardy_mtg is now known as shardy
[15:54] <powersj> smoser: rharper if I want to run a single cloud-init module and pass in user data how do I do that with: cloud-init single -n hostname
[16:05] <smoser> cloud-init single --name=hostname --frequency=always
[16:06] <smoser> and for changing the config that that thing sees....
[16:06] <smoser> i always just end up writing different content into /etc/cloud/cloud.cfg.d/99-smoser.cfg
[16:06] <smoser> and re-running boave
[16:08] <rharper> if you to pass in user-data, you need --file /path/to/cfg
[17:28] <smoser> rharper, blackboxsw https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327532
[17:28] <smoser> that is updated with commits for your feeback (and flake fixes too)
[17:31] <rharper> k
[17:38] <smoser> quick view of https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327896
[17:38] <smoser> would be helpful too
[17:49] <blackboxsw> hrm trying to test freebsd instances with the dhclient changes I can't seem to ssh to the instance w/ root@ec2-..... and the pem file. It's prompting me for a password
[17:49] <blackboxsw> will check those branches now smoser
[17:53] <smoser> hrm indeed. :)
[17:53] <blackboxsw> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327896 approved
[17:54] <blackboxsw> your extensions to mock in https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327532 remind me about adding linters which should balk if we are importing mock directly
[17:56] <smoser> blackboxsw, ?
[17:57] <smoser> i think it doesnt matter though
[17:57] <smoser> unless you know otherwise
[17:57] <smoser> i wondered about this and tested quickly
[17:57] <smoser> if a test does import the 'helpers'
[17:57] <smoser> and then (before or after) import mock via 'import mock'
[17:57] <smoser> then the mock is still patched everywhere
[17:58] <smoser> is that what you were meaning?
[18:01] <blackboxsw> hrm, I lemme check on that. I probably misinterpreted what mock monkey patching we were doing there in helpers.
[18:06] <smoser> blackboxsw, theres only one "copy" of an import
[18:07] <smoser> just differntly namespaced based on how its imported
[18:07] <smoser> right?
[18:07] <smoser> that fact is part of the reason on why you can fail to un-mock something in a unit test and have another unit test affected.
[18:07] <blackboxsw> smoser, ok confirmed the proper behavior as you suggested. Anything that imports helpers will have the properly patch mock.Mock which has assert_not_called since the import already "happened" in original helpers import
[18:08] <blackboxsw> yeah correct
[18:08] <smoser> either before or after
[18:08] <smoser> import mock
[18:08] <smoser> import helpers
[18:08] <smoser> or the other way
[18:08] <smoser> doesn't matter
[18:10] <blackboxsw> so we *don't* have to worry about where we import mock as we have  enxtended mock.Mock at helper module import time
[18:10] <blackboxsw> right
[18:39] <smoser> as long as helper gets loaded
[19:36] <smoser> ugh
[19:36] <smoser> cloud-init in archive now depends on nplan | ifupdown
[19:36] <smoser> updated, then purged ifupdown
[19:37] <smoser> in lxc container
[19:37] <smoser> cleaned out /var/lib/cloud
[19:37] <smoser> reboot
[19:37] <smoser> does not have an ipv4  dhcp address
[19:37] <smoser> :-(
[19:39] <smoser> hm.. maybe it did
[19:48] <larsks> smoser: around?
[20:04] <smoser> larsks, here.
[20:04] <smoser> sorry... slow reply
[20:05] <larsks> No worries.  So, (a) approved for cloud-init summit.
[20:05] <larsks> (b) does this seem like a reasonable explanation of the ovirt issue?
[20:05] <larsks> https://gist.github.com/larsks/62841738dbfad27155628a2560cb818c
[20:06] <smoser> a. \0/
[20:07] <smoser> larsks, that sounds pretty reasonable yes.
[20:07] <larsks> Excellent. Thanks.
[20:07] <smoser> larsks, i think we *could* keep both the instance id and the previous dmi id around and compare
[20:07] <smoser> i think that woudl work.
[20:08] <larsks> Just an extra symlink in /var/lib/cloud/instances, maybe?
[20:08] <smoser> well, cloud-init loads /var/lib/cloud/instance/obj.pkl
[20:08] <smoser> and that, which is the ConfigDrive class
[20:08] <smoser> has the ability to look around and decide if it is new or not
[20:08] <smoser> i think ... (memory here)
[20:09] <smoser> we could keep the uuid from dmi and the instance id.
[20:09] <smoser> and if uuid did not change, we could assume we were same.
[20:09] <larsks> I guess. It seems better if ovirt were to fix things, since they're pretending to be an openstack data source.
[20:09] <smoser> yes.
[20:46] <blackboxsw> hrm, I'm not sure our is_connected function in cloudinit/net/__init__ works on aws cloud instances
[20:46] <blackboxsw> cat /sys/class/net/eth0/carrier
[20:46] <blackboxsw> 1
[20:46] <blackboxsw> I'm seeing a 1 returned from my active eth0 interface (so is_connected returns False)
[20:47] <blackboxsw> ahh wait a sec, sorry n/m. we check iflink first
[20:49] <blackboxsw> ok ignore the peanut gallery: python3 -c 'from cloudinit.net import is_connected; print(is_connected("eth0"))'
[20:49] <blackboxsw> True
[21:18] <smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/327921 should be good now.
[21:48] <rharper> k