[10:15] <smoser> powersj: https://jenkins.ubuntu.com/server/job/cloud-init-copr-build/274/console
[10:15] <smoser> the build that that caused
[10:15] <smoser>  https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/build/724037/
[10:15] <smoser> seems happy
[10:15] <smoser> was that just a transient connection failure or something that caused fail ?
[10:16] <powersj> smoser: I've seen a number of failures on the copr build job. I wanted to look at it this week, but I think I am querying the status field before it even exists
[10:16] <powersj> state*
=== blackboxsw_ is now known as blackboxsw
[16:00] <ajorg> hi!
[16:11] <stanguturi> Hi, Is there a bi-weekly meeting today?
[16:12] <Odd_Bloke> stanguturi: The Canonical people are all at an internal conference this week, so I wouldn't be surprised if it was being skipped.
[16:13] <stanguturi> @odd_bloke: Ok. Thanks for the update.
[16:32] <smoser> yes, we'll do it in 28 minutes
[16:32] <smoser> stanguturi:
[16:32] <smoser> but we're here if you want to chat
[16:41] <smoser> https://gist.github.com/smoser/984af8ead62c7b908f02df82da49c832
[16:43] <smoser> blackboxsw: exec python -m SimpleHTTPServer ${1:-8000}
[16:43] <smoser> minus the 'exec'
[17:00] <blackboxsw> #startmeeting Cloud-init bi-weekly status meeting
[17:00] <meetingology> Meeting started Mon Mar  5 17:00:58 2018 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: action commands idea info link nick
[17:01] <powersj> o/
[17:01] <blackboxsw> hey folks welcome to another episode of Cloud-init status updates. Thanks for coming.
[17:02] <blackboxsw> Since we had a status meeting just prior to the cloud-init upstream release last week there won't be a ton of updates this week.
[17:02] <rharper> o--
[17:02] <blackboxsw> without further ado
[17:02] <blackboxsw> #topic  Recent Changes
[17:03] <blackboxsw> highlight of the last week was the upstream 18.1 release getting cut! Great work folks on getting branches landed in tip proir to release
[17:03]  * blackboxsw grabs powersj highlights 
[17:03] <blackboxsw> cloud-init 18.1 released!
[17:03] <blackboxsw> ds-identify: Fix searching for iso9660 OVF cdroms for vmware (LP: #1749980)
[17:03] <blackboxsw> Documented chef example incorrectly represented apt source configuration for chef install
[17:03] <blackboxsw> SUSE: Fix groups used for ownership of cloud-init.log (Robert Schweikert)
[17:03] <blackboxsw> OVF: Fix VMware support for 64-bit platforms (Sankar Tanguturi)
[17:03] <blackboxsw> Salt: configure grains in grains file rather than in minion config (Daniel Wallace)
[17:03] <blackboxsw> Implement puppet 4 support (Romanos Skiadas)
[17:03] <ubot5`> Launchpad bug 1749980 in cloud-init "ds-identify doesn't properly detect ISO" [High,Fix released] https://launchpad.net/bugs/1749980
[17:04] <blackboxsw> For those that didn't see the email:
[17:04] <blackboxsw> #link https://lists.launchpad.net/cloud-init/msg00144.html
[17:04] <smoser> o/
[17:04] <blackboxsw> thanks again stanguturi  Akihiko and Max Illfelder
[17:06] <blackboxsw> in the ubuntu side of the house we published 18.1 to the Bionic series so clouds now have this by default in bionic images
[17:06] <blackboxsw> Also on the ubuntu-side of the house we finalized an SRU (stable release update) of 17.2.35.2 into both Xenial and Artful, so xenial-updates and artful-updates should have 17.2.35 available (which is only a few commits earlier than the 18.1 release)
[17:10] <blackboxsw> Also in tip post 18.1 we had significant contribution from partners
[17:11] <blackboxsw> Simplify some comparisions. [Rémy Léone]
[17:11] <blackboxsw> Change some list creation and population to literal. [Rémy Léone]
[17:11] <blackboxsw> GCE: fix reading of user-data that is not base64 encoded.
[17:11] <blackboxsw> doc: fix chef install from apt packages example in RTD.
[17:11] <blackboxsw> Implement puppet 4 support [Romanos Skiadas]
[17:11] <blackboxsw> subp: Fix subp usage with non-ascii characters when no system locale.
[17:11] <blackboxsw> salt: configure grains in grains file rather than in minion config. [Daniel Wallace]
[17:11] <blackboxsw> (sorry took me a while to dig up the git formatting options)
[17:12] <blackboxsw> #topic In-progress Development
[17:12] <blackboxsw> We have some existing branches we are trying to get review feedback to folks on:
[17:12] <blackboxsw> #link http://bit.ly/ci-reviews
[17:13] <blackboxsw> Are there reviews that folks feel need some attention this week?
[17:13] <blackboxsw> Internally, we work on items in the TODO/Doing lane of our trello board here:
[17:13] <blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
[17:14] <stanguturi> @blackboxsw: I have one request about the bug https://bugs.launchpad.net/cloud-init/+bug/1724128 Any inputs from cloud-init team will be great.
[17:14] <ubot5`> Ubuntu bug 1724128 in open-vm-tools (Ubuntu) "Need a Success / Failure notification mechanism when cloud-init finishes." [Undecided,New]
[17:15] <blackboxsw> so we have some Snap module development incoming on chrony support, snappy support, vsphere early hostname support
[17:16] <blackboxsw> stanguturi: checking
[17:17] <stanguturi> blackboxsw: Thanks. I discussed this last year in August in cloud-init meeting. Logged this bug long time back. But for some reason, it was not tagged with the proper project. My bad.
[17:18] <blackboxsw> stanguturi: we have an external notification mechanism for scripts to information about when cloud-init has finally completed via "cloud-init status --wait"  .... hrm trying to discuss here about alternative mechanisms internal to cloud-init
[17:21] <blackboxsw> stanguturi: ok we can probably add a publish/subscription mechanism in cloud-init proper for internal eventing that'd get this done.
[17:21] <stanguturi> @blackboxsw: Thanks a lot.
[17:21] <blackboxsw> I've added a topic to our meetings this week to discuss the approach that could make this happen.
[17:21] <blackboxsw> We'll comment on the bug/mailing list with an approach proposal
[17:22] <blackboxsw> #link https://bugs.launchpad.net/cloud-init/+bug/1724128
[17:22] <ubot5`> Ubuntu bug 1724128 in open-vm-tools (Ubuntu) "Need a Success / Failure notification mechanism when cloud-init finishes." [Undecided,New]
[17:22] <blackboxsw> just so I capture the link
[17:23] <stanguturi> @blackboxsw: Thanks I have got another request. I am working on https://code.launchpad.net/~sankaraditya/cloud-init/+git/cloud-init/+ref/vmware-customize-utc-time to add some 'UTC customizations'. Got some review comments from Scott Moser. Can you please provide some pointers to any existing / tests / procedure to add new functionality to distro class
[17:27] <blackboxsw> stanguturi: re-reading ... and checking out the existing cloudinit.distro base module for utc /tz specifics
[17:29] <stanguturi> @blackboxsw: We just want to customize /etc/default/rcS file with some settings on debian platforms.
[17:36] <blackboxsw> hrm, so I'm conflicted with your branch by seeing that Distro.tz_zone_dir  sets that path for for that distro for where TZ information is being configured. I think I'm missing why UTC=yes|no is needed versus Debian.set_timezone
[17:38] <stanguturi> @blackboxsw: This is actually related to 'hwclock'. The key value that needs to be set in /etc/default/rcS is 'UTC' but it's related to 'hwclock' setting.
[17:38] <blackboxsw> for my suggestion on that initial review, I thought that we might need to allow for a Debian-specific method which would handle this additional/separate configuration file processing you were doing w/ /etc/default/rcS
[17:40] <smoser> looking quicklyi it looks like at least recently the correct place to store that is /etc/default/hwclock
[17:40] <smoser>  /etc/default/rcS is read, but per /etc/init.d/hwclock.sh, it looks like /etc/default/hwclock is preferred
[17:41] <smoser> but either way, wahat i think we really want is for the distro class to have a 'store_hwclock_timezone' or something
[17:41] <smoser> and then you'd call into that.
[17:42] <stanguturi> ok. Thanks Scott. Are there any extra test cases / test suites that I need to run if I am modifying the distro class?
[17:42] <blackboxsw> as far as developing additional unit tests for a new distro method: I'd expect new feature methods to be covered in tests/unittests/test_distros/test_debian.py
[17:42] <blackboxsw> also cloud-init summit action we haven't done yet is to move all unittests  out of  tests/unittests and under cloudinit proper
[17:42] <smoser> +1 blackboxsw
[17:44] <stanguturi> ok Will work on that.
[17:44] <blackboxsw> I'll take that test migration action  for any existing modules that are already tested under tests/unittests. The policy we were hoping is that for new modules added under "cloudinit" we'd add a cloudinit/somepath/tests/test_newmodule.py for each cloudinit/somepath/newmodule.py
[17:45] <blackboxsw> so if you want to build on tests/unittests/test_distros/test_debian.py we'll pull that under cloudinit proper when we finally remove tests/unittests altogether
[17:45] <blackboxsw> stanguturi: any other items?
[17:46] <blackboxsw> otherwise I think we'll probably wrap up this meeting  in a few minutes
[17:46] <stanguturi> Yeah. I have one more item. Sorry. https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1750780
[17:46] <ubot5`> Ubuntu bug 1750780 in open-vm-tools (Ubuntu Xenial) "Race with local file systems can make open-vm-tools fail to start" [Undecided,Triaged]
[17:47] <blackboxsw> no worries at all stanguturi we  like the interest
[17:47] <stanguturi> We just noticed that on Ubuntu 18.04 VMs, open-vm-tools service doesn't work with cloud-init.
[17:47] <stanguturi> We didn't have any issues on 17.10. But only found in 18.04
[17:47] <blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1750780
[17:48] <ubot5`> Ubuntu bug 1750780 in open-vm-tools (Ubuntu Xenial) "Race with local file systems can make open-vm-tools fail to start" [Undecided,Triaged]
[17:48] <stanguturi> I first logged the bug https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1667831 and it was fixed and it was mentioned that now the bug 1750780 came up.
[17:48] <ubot5`> Ubuntu bug 1667831 in open-vm-tools (Ubuntu) "cloud-init dependency for open-vm-tools service" [Undecided,Fix released]
[17:51] <smoser> stanguturi: i'll talk with christian tomorrow about the bug there.
[17:52] <stanguturi> ok Thanks Scott.
[17:52] <blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1667831
[17:52] <ubot5`> Ubuntu bug 1667831 in open-vm-tools (Ubuntu) "cloud-init dependency for open-vm-tools service" [Undecided,Fix released]
[17:52] <blackboxsw> ok I think we'll have to call this meeting a close for this week. Thanks again stanguturi for the help/chat here.
[17:53] <blackboxsw> as always I'll post this log to the site:
[17:53] <blackboxsw> #link https://cloud-init.github.io
[17:53] <blackboxsw> #endmeeting
[17:53] <meetingology> Meeting ended Mon Mar  5 17:53:36 2018 UTC.
[17:53] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-03-05-17.00.moin.txt
[17:55] <blackboxsw> dinner time :) have a good one folks
[18:54] <bemis_> Hello, are there any RHEL/derivative users in your dev crew?
[18:55] <bemis_> i ask because line 9 of cloud-init.service.tmpl seems to call in systemd-networkd-wait-online.service which isn't available (yet?) as of el7
[18:56] <bemis_> but as someone just learning the software i'm not sure of the implications of moving htat into the 'ubuntu' if-then
[20:14] <AscII>  
[20:19] <dojordan> @smoser, it appears my C-I run has gotten stuck. Any way to retrigger it? https://jenkins.ubuntu.com/server/job/cloud-init-ci/815/console
[22:01] <dojordan> Hello- I had an infinite loop that is causing my ci build to run forever. Could someone with permission please cancel it? https://jenkins.ubuntu.com/server/job/cloud-init-ci/815/console
[22:22] <blackboxsw> I killed it dojordan
[22:24] <blackboxsw> I see the review responses on your branch, we've talked about instrumenting a trace level debug message, but we haven't had time to prioritize that work yet https://trello.com/c/8cp7exCC/128-cloud-init-logging-trace-level
[22:35] <dojordan> @blackboxsw, makes sense no worries. I've removed the tracing for now. The other thing is the logs will get filled up with the log messages from wait_for_url. If we pass in None as the status callback, then it defaults to LOG.info. Should I pass in a lambda that does nothing?