[00:33] blackboxsw: if you are still around... in your review of the ec2 merge you asked me to add pyyaml to the tox ci env? [02:40] powersj: i think i did auto-op you. [19:02] very confusing [19:02] http://boto3.readthedocs.io/en/latest/reference/services/ec2.html [19:02] look for 'UserData' there [19:02] should you give that as base64 or not? [19:05] smoser: I use https://boto3.readthedocs.io/en/latest/reference/services/ec2.html#EC2.ServiceResource.create_instances that function [19:05] which says UserData='string', [19:06] If you are using a command line tool, base64-encoding is performed for you, and you can load the text from a file. Otherwise, you must provide base64-encoded text. [19:06] and then in bold [19:06] and then right below.. [19:06] yeah :) [19:12] we should figure that out and pass None (or not pass the kwarg) [19:12] rather than b'' [19:20] hrm not understanding why the diff isn't being created here https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/335468 [19:21] might resubmit a third time and avoid prerequisite branch on hogarth's branch as they don't really have to be dependent branches [19:21] no ifrs [19:21] no idea. maybe you have an oops in your inbox [19:23] smoser: I'll look at the b'' shortly [19:54] ok resubmitted the simple fix (not dependent on any branch) [19:54] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/335470 [20:08] smoser: https://paste.ubuntu.com/26223182/ [20:11] wiht **args of course [20:12] powersj: yeah [20:12] i just hit 'submit' on a review there. [20:12] heh I took the t2.micro comment from your last review [20:15] blackboxsw: responded [20:19] smoser: sure on not even bouncing if ifupdown not present, though FreeBSD uses ifconfig down|up. Shall we also check for that ? [20:19] or alternately, if util.is_FreeBSD()? [20:21] it makes things simple to avoid combing through datasource.cfg['hostname_bounce']['command'] for ifdown references [20:23] the only problem I see with not calling bounce_network_with_azure_hostname is that the bounce method actually might be the only thing calling set_hostname in the first place. Will check [20:34] blackboxsw: hm... [20:39] yep, the bounce_network_with_azure_hostname won't actually allow cloud-init to observer #cloud-config\nhostname: mynewname declarations [20:40] on artful/bionic the vm is then left with the hostname it was originally created with in azure's UI/CLI [20:40] because no set-hostname is called [20:41] ? [20:41] confused. [20:42] and that code is confusing [20:42] could show you in hangout. bionic vs xenial behavior, that bounce method is wrapped up in all the get/set_hostname from metadata/user-data calls in the temp_hostname context manager, if we skip it altogether we don't actualy 'see/observe' the user-data hostname provided [20:44] probably best if we don't hangout if you value the rest of your work day ;) [20:52] blackboxsw: ok. hanoug [20:54] yeah, might be worth refactoring that code a bit since I'm touching it. Those two functions are tightly coupled and they probably shouldn't be. [21:01] hmmm console log output isn't always there [21:23] smoser: Xmas list for me: [21:23] - https://code.launchpad.net/~sw37th/cloud-init/+git/cloud-init/+merge/335217 [21:23] python3 only? [21:24] - https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333772 (land as-is and followup with separate refactor branch of yours) [21:25] - and once I've updated this: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/335470