[16:05] look out, It's that time again. [16:05] #startmeeting bi-weekly status meeting [16:05] Meeting started Mon Apr 2 16:05:50 2018 UTC. The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [16:05] Available commands: action commands idea info link nick [16:06] Welcome to the post-Easter episode of cloud-init's status meeting 🐰 [16:06] Today's meeting will probably be light as we are fairly light on attendees given various holiday schedules [16:07] o/ [16:07] nice rabbit ears [16:07] heya! As always, we'll go through recent changes, in progress work and ~30 minutes of office hours [16:08] feel free to interject and ask quesitons at any time. [16:08] #topic Recent Changes [16:09] Here's a brief run down of what we have committed to master in the last couple weeks [16:10] - Support for setting hostname from metadata prior to network bringup. [16:10] This fixes vsphere multi-vm deployments all coming up with the same [16:10] 'ubuntu' hostname. [LP: #1746455](http://pad.lv/1746455) [16:10] - Support initramfs iscsi root so network devices aren't disconnected [16:10] before shutdown [16:10] - Added cloud-config module `cc_snap` which enables loading snap [16:10] assertions, configuring snapd and installing snap packages on Ubuntu. [16:10] Launchpad bug 1746455 in cloud-init "cloud-init vSphere cloud provider DHCP unique hostname issue" [High,Fix released] [16:10] Deprecated `cc_snappy` and `cc_snap_config` modules. [16:10] - Make salt minion work on FreeBSD (Dominic Schlegel) [16:10] [LP:#1721503](http://pad.lv/1721503) [16:10] - Simplify compound conditionals (Rémy Léone) [16:10] Launchpad bug 1721503 in cloud-init "salt module not able to be used on FreeBSD" [Medium,Fix released] [16:10] - Change some list creation and population to literals (Rémy Léone) [16:10] - Add puppet 4 support configurable in `cc_puppet` module (Romanos [16:10] Skiadas) [16:10] - Fix datasouce Azure `get_hostname` function for hostname bounce [16:10] (Douglas Jordan) [LP:#1754495](http://pad.lv/1754495) [16:10] - OpenNebula datasource now uses network config v2 to support IPv6 [16:10] Launchpad bug 1755965 in cloud-init (Ubuntu) "duplicate for #1754495 util.subp regression: no longer accept commands as string" [Critical,Fix released] [16:10] config (Akihiko Ota) [16:10] - Add Hetzner Cloud datasource support (Markus Schade) [16:11] The highlights of this work that will affect various clouds: hostname setting before network bringup, in cloud-init's init-local stage. [16:12] so if your cloud's metadata provides hostname information (per your instance creation) that hostname gets set before any potential dhcp discovery on the instance. This is a big win for Azure and may allow us to avoid/deprecate some of the hostname_bounce functionality [16:13] which was baked in to re-dhcp in order to publish updated hostname information to DDNS [16:14] We also have landed support for two new clouds: Hetzner Cloud and IBMCloud. A big thanks to Markus Schade for the Hetzner work there and smoser for the IBMCloud datasource [16:15] do3meli (Dominic Schlegel) has also been on a blitz fixing and updating a lot of FreeBSD support in cloud-init tip so thank you sir for that work as well. [16:16] We've just also landed some zfs resize support by rharper as well that should be making it's way into your friendly neighborhood Ubuntu Bionic series in a cloud near you [16:16] anything else I'm missing on rharper or powersj ? [16:16] ahh hold the phone [16:16] blackboxsw: well, not my zfs-resize [16:17] but I do have some fixes for it [16:17] https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+ref/fix/cc_resizefs_on_zfs_root [16:17] We officially released cloud-init 18.2 in master. There is an 18.2 tag in the repo for folks wanting to take an early cut of it. [16:17] our ci-test backend normally runs with zfs, it's not right now so it missed a couple edge cases that we need to handle [16:18] Per cloud-init 18.2 here is an email sent to the cloud-init mailing list describing the details: https://lists.launchpad.net/cloud-init/msg00145.html [16:18] #link https://lists.launchpad.net/cloud-init/msg00145.html [16:18] #link https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+ref/fix/cc_resizefs_on_zfs_root [16:19] #topic In-progress Development [16:20] The upstream team has released 18,2 to Bionic as of last week, and we started an Ubuntu SRU process into Xenial and Artful. [16:21] We expect the 18.2 to be present in Xenial and Artful within 2 weeks in your cloud, so if you are waiting on a feature, it won't be very long. [16:22] Also in-progress are some of rharper's zfs fixes, and some exception callback cleanup that will affect Azure, EC2, OpenStack and Scaleway clouds. [16:22] #link https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+ref/fix/cc_resizefs_on_zfs_root [16:22] #link https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/342007 [16:23] And we are doing our part to finally purge net-tools dependencies from cloud-init (in favor of iproute2) [16:23] #link https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/342428 [16:24] blackboxsw: I responded to your ip -6 route q from last week, did you see that ? [16:24] rharper: haven't yet, but I'll grab those comments today for sure (I think I missed some of your earlier review comments) [16:24] ok [16:25] the tl;dr for that one is that you want this: ip -6 route list table all [16:25] ahh excellent, I was wondering why we were missing content for local routes etc [16:25] right [16:25] thanks [16:26] np [16:26] also, on our continuous integration front , powersj has put up a branch that I'd like to see us land with some ssh improvements [16:26] #link https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/342010 [16:26] :) yep [16:26] any other in-progress work worth noting? [16:27] Intereseted parties can always track our public trello board for a glimpse of what we are working on [16:27] #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin [16:27] #topic Office Hours (next ~30 minutes) [16:28] We'll all have eyes glued to the screen for the next 30 minutes for rants, feature discussion and bug work. [16:29] With that, the floor is open for any topics. Thanks for tuning in. [16:30] My day today will be Ubuntu SRU(stable release update)-related, so I'm getting on rharper's zfs branch now and they running a couple manual tests on ec2/azure/openstack [16:30] +1 [16:30] oh, the ntp-spec update is ready for review and testing [16:31] https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438 [16:32] ahh +1 we want that in too [16:32] #link https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438 [17:02] Alrighty, happy spring break all. [17:02] Next meeting will be two weeks from today. [17:03] powersj: rharper 4/16 look good for folks? [17:03] +1 from me === blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 4/16 16:00 UTC | cloud-init 18.2 released (03/28/2018) [17:03] #endmeeting [17:03] Meeting ended Mon Apr 2 17:03:58 2018 UTC. [17:03] Minutes: http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-04-02-16.05.moin.txt [18:26] rharper: done with https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/342467 [18:26] minor nit [18:26] k [18:32] blackboxsw: added [18:32] pushed update [19:25] blackboxsw: ci says yes, are you going to run the lander or should I for the merge ? [19:26] rharper: yep, yep, I'll run the lander. I was just getting through your ntp one [19:26] cool [19:27] couple doc nits (on all schema dedent) I'll just post that now. How do I ascertain on timsyncd that the proper settings were honored, systemctl status systemd-timesyncd is not really too helpful [19:27] default timsync service detection looks to work fine on ubuntu [19:27] just going though a couple of tests [19:34] landed https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/342467 [19:36] blackboxsw: we *cant* really [19:37] so the ci-test checks that we wrote the conf file correctly [19:37] hrm, also when I have ntp installed, should I expect timesyncd to also report that it is configured and running? [19:37] via journalctl -u systemd-timesyncd.service, if you know the ips, it shows you stuff, but there is no *direct* way to confirm configuration [19:37] Active: active (running) since Mon 2018-04-02 19:34:37 UTC; 2min 15s ago [19:37] so, in containers, no [19:38] ntp is special in that it just continues even if it can't modify host clock (you'll see a failure due to missing CAP_SYS_TIME) [19:38] but, timesyncd and chrony both have a CondtionContainer! [19:38] which prevents them from actually starting in a container [19:38] % journalctl -o short-precise -u systemd-timesyncd [19:38] -- Logs begin at Thu 2018-03-15 18:44:40 CDT, end at Mon 2018-04-02 14:38:12 CDT. -- [19:38] Mar 20 16:07:20.165833 neipa systemd-timesyncd[1962]: Timed out waiting for reply from [2001:67c:1560:8003::c8]:123 (ntp.ubuntu.com). [19:39] I'm on ec2 instances which is xen right. [19:40] ah, that should work fine [19:40] https://www.irccloud.com/pastebin/rZTvr122/ [19:40] yeah, vms are OK [19:41] containers which share the same kernel (and time) don't need to sync themselves [19:41] yeah, I just forgot if there was a conflict issue w/ timesyncd or ntp where one or the other realizes that another client is running an falls over [19:41] vms maintain their own clock offset due to how time is kept (in registers) [19:41] so, xenial only, timesyncd won't stop if ntp or any other client is installed [19:41] ok yeah I'm on xenial and seeing that [19:41] in bionic, there is a conficts in timesyncd config which forces timesyncd to stop if ntp/chrony is installed [19:42] thanks for the context. had forgotten [20:45] rharper: another round on ntp https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438 [20:45] I'm almost there. [20:45] but I'll probably have a few more comments [20:45] sure [20:52] blackboxsw: ok, I already pushed the rebase to drop the zfs, and I *think* all of the doc changes; working on the rest of your comments [20:56] blackboxsw: maybe you can help, the decode_text() is subtly different than decode_binary(); note we testing if the input is a six.binary_type and if so decode, where as the other case test if it's a string-type and converts; [20:56] s/check_exec/check_exe/ throughout [20:56] oops, I may have misread those functions. looking again [20:57] blackboxsw: generally this was to work around the fact that if we util.load_file() on our chrony template, we get a UTF-8 char that's not decodeable without specifying the encoding value, py27 needed this before we call the jinja template render code [21:16] hrm, not specifically hitting the problem just on load_file but you are talking during template render we hit this issue? [21:17] load_file in py27 on all template files worked for me the additional decode_text. and I see you folded that into the detect_template call; will check [21:20] rharper: dpb1 I know I'm not going to be able to wrap up the ntp spec branch reviews today and I'd like to get both that and powersj branch in before we re-upload to bionic and start a refresh on the SRU into xenial and artful. So, can we wait to post a bionic upload on zfs fixes until tomorrow? [21:21] rharper: I'm looking to you for "criticality" on zfs resize how much do we want to do two uploads to bionic today and tomorrow? [21:22] * dpb1 parses [21:22] blackboxsw: tox -e py27 blows up without the decode_text wrapper when redendering from the "real" templates in tree [21:23] blackboxsw: rharper, I mean, we should put all those in the upload to bionic, why waste cycles? [21:23] tomorrow sounds like a better target [21:23] right, I'm for waiting on uploads to bionic until we get everything we want [21:23] on one hand, there is no reason to wait [21:23] it's like "committing" your source code [21:23] right, push what we want (or can) to master today, and then prepare an upload tomorrow [21:23] however [21:24] in this case, we don't have the upload rights at work [21:24] right, commiting the source code is easy, but upload rights being the 'hard' at the moment [21:24] so, let's just be a bit judicious [21:24] :) [21:24] ok thx [21:24] will continue on ntp spec branch review/assessment [21:24] ok [21:24] yes, lining it up for tomorrow: +1 [21:24] instead of changing gears for upload [21:25] tomorrow it is [21:52] ok rharper I think I'm done on ntp config comments. a couple more timeconsuming changes requested for ntp config validation. [21:53] sure