[13:44] <plujon> I'm not sure if this is a cloud-init question... I have an Ubuntu 16.04.5 Digital Ocean droplet.  Yesterday I ran `apt-get update && apt-get dist-upgrade`, and after rebooting, found my ssh server keys had changed.  Further digging reveals that cloud-init generated new ssh keys for my server.  Why would it do that?
[14:09] <smoser> plujon: if it thoguht you were on a new instance it would do that.
[14:09] <smoser> it should not do that unless you captured a snapshot and created a new instance from that.
[14:09] <smoser> if you could post /var/log/cloud-init.log that'd be nice.
[14:10] <smoser> and if you can file a bug and attach 'cloud-init collect-logs' that would have more info for us.
[14:10] <smoser> you can run 'ubuntu-bug' and follow prompts
[14:10] <smoser> plujon: thank you for asking.
[14:20] <plujon> smoser: The /var/log/cloud-init.log is rather big!  I wonder if this is the relevant piece:
[14:20] <plujon> http://ix.io/1ka2
[14:20] <plujon> That's a pair of warnings from journalctl.
[14:24] <plujon> And from cloud-init.log, the key regeneration: http://ix.io/1ka8
[14:25] <plujon> I'm hesitant to file a bug because it might be something Digital Ocean does intentionally, for some inexplicable reason.
[14:33] <smoser> plujon: are you not wanting to paste things?
[14:33] <smoser> pastebinit /var/log/cloud-init.log will do it for you
[14:34] <smoser> wrt if it is intended or not... i would suspect it is not.
[14:35] <smoser> just showing that it *did* regenerate keys (i believed you the first time) isn't really helpful. the full is needed to see why.
[14:36] <smoser> if you're afraid of personal data being exposed, and you feel morme comfortable sharing with me privately that is fine too.
[14:59] <plujon> smoser: http://paste.ubuntu.com/p/X3CpJqhj6m/
[15:05] <smoser> plujon: thanks. i'll take a looka fter this call.. 15 minutes or so
[15:11] <brtknr> Is the command for running tests simply "tox"
[15:12] <brtknr> ERROR: FAIL could not package project - v = InvocationError('/usr/bin/python2 /opt/bharat/cloud-init/setup.py sdist --formats=zip --dist-dir /opt/bharat/cloud-init/.tox/dist (see /opt/bharat/cloud-init/.tox/log/tox-0.log)', 1)
[15:12] <brtknr> I get this when i try to run tox
[15:12] <brtknr> ERROR: invocation failed (exit code 1), logfile: /opt/bharat/cloud-init/.tox/log/tox-0.log
[15:12] <brtknr> ERROR: actionid: tox
[15:12] <brtknr> msg: packaging
[15:12] <brtknr> cmdargs: ['/usr/bin/python2', local('/opt/bharat/cloud-init/setup.py'), 'sdist', '--formats=zip', '--dist-dir', local('/opt/bharat/cloud-init/.tox/dist')]
[15:12] <brtknr> Traceback (most recent call last):
[15:12] <brtknr>   File "setup.py", line 272, in <module>
[15:12] <brtknr>     version=get_version(),
[15:12] <brtknr>   File "setup.py", line 83, in get_version
[15:13] <brtknr>     (ver, _e) = tiny_p(cmd)
[15:13] <brtknr>   File "setup.py", line 48, in tiny_p
[15:13] <brtknr>     (cmd, ret, out, err))
[15:13] <brtknr> RuntimeError: Failed running ['/usr/bin/python2', 'tools/read-version'] [rc=1] (, git describe version (17.2-187-gf6249277) differs from cloudinit.version (18.3)
[15:13] <brtknr> )
[15:13] <brtknr> ERROR: FAIL could not package project - v = InvocationError('/usr/bin/python2 /opt/bharat/cloud-init/setup.py sdist --formats=zip --dist-dir /opt/bharat/cloud-init/.tox/dist (see /opt/bharat/cloud-init/.tox/log/tox-0.log)', 1)
[15:17] <brtknr> Okay it worked after changing version inside cloudinit/version.py from 18.3 to 17.2
[15:17] <blackboxsw> brtknr: what distro?
[15:18] <brtknr> centos
[15:18] <blackboxsw> 7 or 6?
[15:18] <blackboxsw> I have an image here, will double check tip vs an older version
[15:18] <brtknr>  7.5.1804
[15:19] <blackboxsw> thx will check
[15:24] <smoser> plujon: thanks. there is a bunch of bugs represented there... :-(
[15:25] <plujon> smoser: Heh, you are welcome!
[15:25] <smoser> this was a 14.04 upgraded ?
[15:26] <plujon> smoser: Hmm.  Good question.  Let me see...
[15:28] <plujon> The machine was initiated on 2016-11-07.  I think it was 16.04.
[15:29] <smoser> plujon: you're probably right. i didnt realise/remember that 16.04 started with such an old version
[15:29] <smoser> but you are correct. GA was 0 .7.7
[15:29] <smoser>  https://launchpad.net/ubuntu/+source/cloud-init
[17:19] <blackboxsw> hrm smoser one issue with hoisting EphemeralDCHP up into get_data is that _poll_imds (called by crawl_metadata) needs access to the dhcplease lease as well as retrying the EphemeralDHCP context manager  on urlerror.
[17:20] <blackboxsw> I'll try thinking about how to consolidate both callsites
[17:34] <smoser> hm.
[18:53]  * blackboxsw doesn't believe we need the EphemeralDCHP within a try/except UrlError...  loop for Azure._poll_imds.  I'll try pulling it up into get_data and just passing the lease info into _poll_imds(lease)
[19:23] <blackboxsw> hmm but passing the lease into crawl_metadata poses a problem because that call signature needs to be common across all DataSources :/
[19:23] <blackboxsw> I guess I could persist an instance variable DSAzure.dhcp_lease
[19:24] <blackboxsw> this feels dirty/brokne
[19:24] <blackboxsw> this feels dirty/broken
[19:24] <smoser> hm..
[19:40] <blackboxsw> the whole point of EphemeralDHCPv4 is quickly setting up network for a short period of time and tearing it down afterward, hence the context manager, but this doesn't quite align w/ poll_imds which wants to repeatedly attempt to hit dhclient to get new addressess across a polling loop exception boundary.
[19:41] <rharper> blackboxsw: can we subclass into a PollingEphemeralDHCP ?
[19:41] <blackboxsw> it kinda feels like poll_imds should be our greater context....
[19:42] <blackboxsw> rharper: yeah I kinda feel like that rework needs to happen, PollingEphemeralDHCP., like the name,
[19:42] <blackboxsw> then we'd have one single context which would result in a properly configured network when we clear that 'gate'
[19:43] <blackboxsw> ok that feels a bit like rework/tech-debt that'd involve a bit more eyes (like azure folks too) to weigh in
[19:44] <blackboxsw> because I need access to a configured test/dev platform which blocks on imds polling
[19:44] <blackboxsw> to validate behavior
[19:48] <rharper> heh
[19:48] <rharper> yeah
[20:12] <shaner> smoser: really appreciate the review, will work on making the necessary fixes
[20:27] <smoser> shaner: great. please feel free to ping. and also if i'm delinquent feel free to ping.
[20:28] <shaner> smoser: ack, will do
[20:32] <smoser> rharper: what is the 'manual' word for netplan
[20:32] <rharper> Requried for somethin g
[20:33] <smoser> :-(
[20:33] <smoser> required for boot != please do not bring up automatically
[20:33] <rharper> oh, critical connection
[20:33] <cyphermox> no
[20:33] <rharper> you said mainly which means 'ignore me'
[20:34] <cyphermox> there's no such thing as "manual".