=== r-daneel_ is now known as r-daneel
[15:09] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/347559
[15:14] <blackboxsw> https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-lxd-a/373/console has a set of ntp/warning errors I hadn't looked at yet
[15:49] <smoser1> powersj: jenkins seems not to be working ?
[15:49] <smoser1> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347698
[15:50] <smoser1> oh wait. yes it is.
=== smoser1 is now known as smoser
[15:57] <powersj> smoser: I believe the issue there is master was broken yesterday due to another pylxd issue with imports
[15:57] <powersj> blackboxsw put in a merge https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/347637
[15:59] <blackboxsw> yeah, powersj looks like pylxd just posted an update to tip which may or may not have resolved that problem so we might be able to revert my changes now
[16:06] <smoser> powersj: yeah, i was wrong.s orry. i thought it hant run.
[16:07] <smoser> blackboxsw: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347702 has the upstream change.
[16:07] <blackboxsw> good thx smoser will test and land it
[16:11] <smoser> blackboxsw: i'mve got a land in progress now for the subp change i had . so just make sure not to fight on that.
=== r-daneel_ is now known as r-daneel
[16:13] <blackboxsw> smoser: I'm awaiting a jenkins CI approve vore on your tox/lxd branch first. so should be about 15 mins until I kick something off. will check before I do
[16:13] <smoser> right
[16:13] <blackboxsw> ... and review-mps should react appropriately now by stopping the land attempt :)
[16:13] <blackboxsw> or failing locally rather, instead of updating the branch before trying to git push
[16:13] <blackboxsw> or failing locally rather, instead of updating the *branch status in LP* before trying to git push
[16:23] <smoser> rharper: you can take a quick https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347698 your comment is aresse there.
[16:23] <rharper> y
[17:51] <blackboxsw> rharper: done with your mtu review comments sysconfig fixed (it never honored device-level mtu in the first place, only subnet-level). Added unit test validation of warning message emitted on sysconfig/eni/netplan rendering)
[17:51] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/347559 should be clear
[18:32] <rharper> blackboxsw: ok; yes, sysconfig render path typically involves openstack which network_data.json always uses subnet config but thanks for adding
[19:05] <blackboxsw> rharper: done; only warn on differing mtu @ device-level vs subnet-level
[19:05] <rharper> cool
[19:06] <blackboxsw> I'll watch the branch for the approve or otherwise.
[19:08] <rharper> blackboxsw: did you add a test where we skip the warn (device and subnet mtu, both are the same value) ?
[19:09] <blackboxsw> ahh nope, will add a separate test
[19:59] <smoser> man
[20:04] <blackboxsw> was that a part-handler utf-8 man smoser?
[20:05] <smoser> yeah. i am lost
[20:05] <blackboxsw> yeah isn't it crazy/weird. hard to get pdb's and log traces on it :/
[20:05] <smoser> i used to be able to do this.
[20:05] <smoser> to get a pdb from cloud-init
[20:06] <blackboxsw> it's 'string' type in py3 both with and without utf-8 content... so I was unable to see simple type differences and log won't print out the utf-8 content/and traceback is swallowed there :/
[20:07] <blackboxsw> anyway, /me is adding things a --preserve-instance option to ci tests so we avoid the teardown (to grab salt && chrony issues)
[20:07] <smoser> ah. k
[20:31] <blackboxsw> powersj: smoser rharper https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/347716
[20:31] <blackboxsw> minor tweaks that help be get ahold of an integration instance under test using out ci
[20:31] <smoser> ok.
[20:31] <smoser> so the one thing i've found out here.
[20:31] <smoser> well, two things.
[20:31] <smoser> a.) man, what a mess.
[20:31] <smoser> b.) _CLOUD_INIT_SAVE_STDOUT=1 _CLOUD_INIT_SAVE_STDIN=1 cloud-init --debug init
[20:32] <blackboxsw> leaves a message like:  2018-06-08 20:20:20,632 - tests.cloud_tests - INFO - Preserving test instance cloud-test-ubuntu-artful-modules-ntp-chrony-a6v27keuq27i794lru2
[20:32] <smoser> that will let pdb (or ipdb break in)
[20:33] <blackboxsw> wow smoser, ok maybe we add that to hacking docs on rtd, or maybe just cloud-init docs in ubuntu-sru repo?
[20:33] <smoser> :)
[20:33] <blackboxsw> yeah I've frequently tried/failed pdb using cloud-init's cli
[20:33] <blackboxsw> didn't spend enough time to unravel it
[20:33] <blackboxsw> that is a good tip that I'd like to reference in the future... .checking it now to hopefully commit it to muscle-memory (bashhistory memory)
[20:34] <blackboxsw> or a gist :)
[20:41] <blackboxsw> hrm I think our integration tests are seeing https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1589780
[20:41] <ubot5> Ubuntu bug 1589780 in chrony (Ubuntu) "chrony.service doesn't start on LXD container" [High,Fix released]
[20:41] <blackboxsw> on artful
[20:42] <blackboxsw> digging a bit more
[20:42] <blackboxsw> but generally chrony isn't starting up with something like chronyd[190]: Fatal error : adjtimex(0x8001) failed : Operation not permitted
[20:43] <blackboxsw> will have to talk to cpaelzer_ about this on Monday
[20:44] <smoser> that is expected
[20:44] <smoser> blackboxsw: well that bug is not marked as fixed in artful
[20:44] <blackboxsw> as a result maybe we just shouldn't be testing chrony cloud-config on artful right?
[20:44] <blackboxsw> because it results in errors which we expect (chrony support bionic++ right?)
[20:45] <smoser> well, it isnt expected to work
[20:45] <blackboxsw> yeah, I'm going to disable that ntp_chrony test on artful then.
[20:45] <blackboxsw> wanted to air that thought for objections
[20:47] <smoser> well, in a container.
[20:47] <smoser> i guess.
[20:47] <smoser> it could/should run on ec2 ?
[20:47] <smoser> or non-lxd
[20:48] <blackboxsw> will verify. yeah I  think it's just a container where it fails
=== blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 6/18 16:00 UTC | cloud-init 18.2 released (03/28/2018)
[20:55] <smoser> blackboxsw: wel...
[20:55] <smoser> we lose the data when we call 'convert_string'
[20:55] <smoser> in UserDataProcessor:process
[20:58] <blackboxsw> email sent moving cloud-init status meeting one week
[20:58] <blackboxsw> oooh :(
[21:01] <smoser> ok... i have to leave for the night :-(
[21:01] <smoser> blackboxsw: so what happens is that when we're storing this to disk in the mime format
[21:02] <smoser> we call
[21:02] <smoser> convert_string(raw_data)
[21:02] <smoser> which raw_data is a bytes
[21:02] <smoser> then util.decode_binary(blob) returns a string that includes utf-8
[21:02] <smoser> then we end up doing
[21:03] <smoser> email.message_from_string(that_string)
[21:03] <smoser> so..
[21:04] <smoser> msg = email.message_from_string(b"echo hi \xc3\x84\n".decode('utf-8'))
[21:04] <smoser> msg.as_string()
[21:04] <smoser> works, but
[21:05] <smoser> msg.as_bytes()
[21:05] <smoser> UnicodeEncodeError: 'ascii' codec can't encode character '\xc4' in position 8: ordinal not in range(128)
[21:06] <smoser> and then we read that with fully_decoded_payload
[21:06] <smoser> its somewhere in there.
[21:06] <smoser> ... i'm sorry . i have to run for now.
[21:07] <smoser> i figured i could have solved this in the afternoon, which is why i took it.
[21:07] <smoser> :-(
=== r-daneel_ is now known as r-daneel
[21:17] <blackboxsw> yeah it's nasty the # of conversions
=== r-daneel_ is now known as r-daneel