[13:44] 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] plujon: if it thoguht you were on a new instance it would do that. [14:09] it should not do that unless you captured a snapshot and created a new instance from that. [14:09] if you could post /var/log/cloud-init.log that'd be nice. [14:10] and if you can file a bug and attach 'cloud-init collect-logs' that would have more info for us. [14:10] you can run 'ubuntu-bug' and follow prompts [14:10] plujon: thank you for asking. [14:20] smoser: The /var/log/cloud-init.log is rather big! I wonder if this is the relevant piece: [14:20] http://ix.io/1ka2 [14:20] That's a pair of warnings from journalctl. [14:24] And from cloud-init.log, the key regeneration: http://ix.io/1ka8 [14:25] I'm hesitant to file a bug because it might be something Digital Ocean does intentionally, for some inexplicable reason. [14:33] plujon: are you not wanting to paste things? [14:33] pastebinit /var/log/cloud-init.log will do it for you [14:34] wrt if it is intended or not... i would suspect it is not. [14:35] 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] if you're afraid of personal data being exposed, and you feel morme comfortable sharing with me privately that is fine too. [14:59] smoser: http://paste.ubuntu.com/p/X3CpJqhj6m/ [15:05] plujon: thanks. i'll take a looka fter this call.. 15 minutes or so [15:11] Is the command for running tests simply "tox" [15:12] 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] I get this when i try to run tox [15:12] ERROR: invocation failed (exit code 1), logfile: /opt/bharat/cloud-init/.tox/log/tox-0.log [15:12] ERROR: actionid: tox [15:12] msg: packaging [15:12] 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] Traceback (most recent call last): [15:12] File "setup.py", line 272, in [15:12] version=get_version(), [15:12] File "setup.py", line 83, in get_version [15:13] (ver, _e) = tiny_p(cmd) [15:13] File "setup.py", line 48, in tiny_p [15:13] (cmd, ret, out, err)) [15:13] 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] ) [15:13] 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] Okay it worked after changing version inside cloudinit/version.py from 18.3 to 17.2 [15:17] brtknr: what distro? [15:18] centos [15:18] 7 or 6? [15:18] I have an image here, will double check tip vs an older version [15:18] 7.5.1804 [15:19] thx will check [15:24] plujon: thanks. there is a bunch of bugs represented there... :-( [15:25] smoser: Heh, you are welcome! [15:25] this was a 14.04 upgraded ? [15:26] smoser: Hmm. Good question. Let me see... [15:28] The machine was initiated on 2016-11-07. I think it was 16.04. [15:29] plujon: you're probably right. i didnt realise/remember that 16.04 started with such an old version [15:29] but you are correct. GA was 0 .7.7 [15:29] https://launchpad.net/ubuntu/+source/cloud-init [17:19] 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] I'll try thinking about how to consolidate both callsites [17:34] 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] hmm but passing the lease into crawl_metadata poses a problem because that call signature needs to be common across all DataSources :/ [19:23] I guess I could persist an instance variable DSAzure.dhcp_lease [19:24] this feels dirty/brokne [19:24] this feels dirty/broken [19:24] hm.. [19:40] 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] blackboxsw: can we subclass into a PollingEphemeralDHCP ? [19:41] it kinda feels like poll_imds should be our greater context.... [19:42] rharper: yeah I kinda feel like that rework needs to happen, PollingEphemeralDHCP., like the name, [19:42] then we'd have one single context which would result in a properly configured network when we clear that 'gate' [19:43] 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] because I need access to a configured test/dev platform which blocks on imds polling [19:44] to validate behavior [19:48] heh [19:48] yeah [20:12] smoser: really appreciate the review, will work on making the necessary fixes [20:27] shaner: great. please feel free to ping. and also if i'm delinquent feel free to ping. [20:28] smoser: ack, will do [20:32] rharper: what is the 'manual' word for netplan [20:32] Requried for somethin g [20:33] :-( [20:33] required for boot != please do not bring up automatically [20:33] oh, critical connection [20:33] no [20:33] you said mainly which means 'ignore me' [20:34] there's no such thing as "manual".