=== cpaelzer__ is now known as cpaelzer [14:41] I'm looking at https://bugs.launchpad.net/cloud-init/+bug/1843221 for triage, and I'm not sure what to recommend the user do. They're using NoCloud, so I think they probably could specify network config, but am I missing a way for a user without that option to configure DNS in a system? [14:41] Launchpad bug 1843221 in cloud-init "manage_resolv_conf not working in ubuntu18.04 cloud images" [Undecided,New] [15:01] Odd_Bloke: i think that was teh right answer [15:54] hey, could you please take a look at https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/368507 and https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/365641 [15:55] rharper: Looks like you've reviewed those two branches previously. [16:25] annnd it's that time for real: cloud-init status meeting. [16:26] #startmeeting Cloud-init bi-weekly status [16:26] Meeting started Mon Sep 9 16:26:10 2019 UTC. The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [16:26] Available commands: action commands idea info link nick [16:27] Hey folks, welcome to the ~biweekly cloud-init status meeting. [16:28] #chair rharper Odd_Bloke [16:28] Current chairs: Odd_Bloke blackboxsw rharper [16:28] o/ [16:28] cloud-init upstream uses this meeting as a platform for community updates, feature/bug discussions, and an opportunity to get some extra input on current development. [16:30] Feel free to interject at any time. Our typical format is the following: Previous Actions, Recent Changes, In-progress Development, Office Hours (~30 mins) [16:30] Last meeting's minutes live here: [16:30] #link https://cloud-init.github.io/status-2019-08-19.html#status-2019-08-19 [16:30] #topic Previous actions [16:31] no actions from last meeting so we'll plow right through to Recent Changes [16:31] #topic Recent Changes [16:32] The following branches have landed in tip since last meeting: via git log --since 2019-08-19 [16:32] - doc: document doc, create makefile and tox target [Joshua Powers] [16:32] - .gitignore: ignore files produced by package builds [Daniel Watkins] [16:32] - docs: fix whitespace, spelling, and line length [Joshua Powers] [16:32] - docs: remove unnecessary file in doc directory [Joshua Powers] [16:32] - Oracle: Render secondary vnic IP and MTU values only [Ryan Harper] [16:32] - exoscale: fix sysconfig cloud_config_modules overrides [16:32] [Chad Smith] (LP: #1841454) [16:32] Launchpad bug 1841454 in cloud-init "Exoscale datasource overwrites *all* cloud_config_modules" [Undecided,Fix committed] https://launchpad.net/bugs/1841454 [16:32] - net/cmdline: refactor to allow multiple initramfs network config sources [16:32] [Daniel Watkins] [16:32] - ubuntu-drivers: call db_x_loadtemplatefile to accept NVIDIA EULA [16:32] [Chad Smith] (LP: #1840080) [16:32] Launchpad bug 1840080 in cloud-init (Ubuntu) "cloud-init cc_ubuntu_drivers does not set up /etc/default/linux-modules-nvidia" [High,Fix released] https://launchpad.net/bugs/1840080 [16:32] - Add missing #cloud-config comment on first example in documentation. [16:32] [Florian Müller] [16:32] - ubuntu-drivers: emit latelink=true debconf to accept nvidia eula [16:32] [Chad Smith] (LP: #1840080) [16:32] - DataSourceOracle: prefer DS network config over initramfs [16:32] [Daniel Watkins] [16:32] - format.rst: add text/jinja2 to list of content types (+ cleanups) [16:32] [Daniel Watkins] [16:32] - Add GitHub pull request template to point people at hacking doc [16:32] [Daniel Watkins] [16:34] Additionally: we have also cut a stable-18.4 branch from the 18.4 tag as our last supported python2.6 branch. There will be an email sent out to the mailing list about the intent of this branch. It requires a couple of minor fixes to make sure py2.6 support is functional, but this will be reference branch for any distribution that does not have access to py.27 or later. No additional feature development is [16:34] planned on stable-18.4 [16:37] a reminder again that python2.6 support was 'dropped' in cloud-init upstream as of the 18.4 release, so expectations for py2.6 support stopped in 18.4 and there is a deprecation plan for py 2.7 as well [16:37] #link https://lists.launchpad.net/cloud-init/msg00170.html [16:37] Again, see the mailinglist for details and updates [16:37] #link https://lists.launchpad.net/cloud-init/ [16:38] #topic In-progress Development [16:38] Last week or so the team has been working on SRU validation for cloud-init 19.2.24 into Xenial, Bionic and Disco. [16:39] We have passed all SRU validation tests and our expected pubish date for 19.2.24 is tomorrow for those Ubuntu series [16:40] good work on validation folks [16:41] and thanks for extra cloud-init community verification from exoscale, azure and VMware for validation efforts [16:42] There is additional Oracle, FreeBSD and Azure work in flight at the moment as well as some boot speed improvements and analysis from rharper [16:43] The following link represents any carded work upstream is tracking. The Doing lane is content or features we expect to land shortly [16:43] #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin [16:47] Now is probably a good time to also mention that our entire ubuntu server team also reflects our weekly accomplishements over in the ubuntu-server discourse. If there are deeper discussions or questions on various topics or features please join us there as well [16:47] #link https://discourse.ubuntu.com/c/server [16:48] I think that about wraps it for in-progress development [16:48] #topic Office Hours (next ~30 mins) [16:48] upstream cloud-init devs will have eyes on this channel for any discussions, questions, bugs or feature work the greater community would like to discuss. [16:49] During this time, we'll also groom our activereview queue to make sure we try to get review comments out to devs who have active branches. [16:49] Again, thanks for tuning in [16:57] Ok just addressed review comments on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/372432 . I'm reviewing https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/368507 [16:59] * blackboxsw also sets the next meeting topic so we don't forget. [17:01] Odd_Bloke: rharper powersj, I *think* we decided to shift from Mondays to Tuesdays for status meetings to avoid collisions with holidays, vacation work travel etc. Are we doing that for next status meeting, or maybe waiting to discuss that more broadly? [17:02] Tuesday in two weeks is likely to be a travel day for anyone heading to the cloud-init summit. [17:02] But Monday is likely to be a swap day for Canonical folks because we're all travelling next week too. [17:03] hrm right, maybe we wait then and discuss at the summit [17:03] So I would perhaps suggest skipping the next meeting, and then we can resume on Tuesdays two weeks after the summit? [17:03] discuss scheduling changes that is [17:03] sure, let's push/postpone until summit +2 weeks === blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting Oct 8 16:15 UTC | cloud-init v 19.2 (07/17) | https://bugs.launchpad.net/cloud-init/+filebug [17:05] #action blackboxsw send email to the list notifying of status meeting day change. [17:05] ACTION: blackboxsw send email to the list notifying of status meeting day change. [17:10] +1 Odd_Bloke [17:11] Also note that the version of cloud-init that has undergone SRU verification is also published to our copr el-testing repo. We only update that repo during upstream cloud-init releases XX.YY and any Ubuntu SRUs so it is much more stable than our daily copr repo. [17:11] #link https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/ [17:33] I think that about wraps our cloud-init status meeting for today. I'm wrapping up my review here and will post it to the set_passwords branch. [17:33] #endmeeting [17:33] Meeting ended Mon Sep 9 17:33:31 2019 UTC. [17:33] Minutes: http://ubottu.com/meetingology/logs/cloud-init/2019/cloud-init.2019-09-09-16.26.moin.txt [17:35] minutes published to https://cloud-init.github.io/status-2019-09-09.html#status-2019-09-09 [17:35] thanks folks [18:02] blackboxsw: Thanks for running the meeting! [18:05] Odd_Bloke: no prob [18:06] rharper: Goneri I finished my review of https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/368507 a couple comments/suggestion inline for you both to weigh in on. thanks again [18:06] Odd_Bloke: sorry, do we use 'Fixes LP: #XXXXX' now ? [18:06] I'm +1 on that approach but had a couple of suggestions [18:06] https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/372491 [18:06] in your commit message. versus just ^LP: #XXXXX [18:07] smoser: Odd_Bloke haha that is because Dan's mind is doing github branches for ubuntu-advantage-tools [18:07] cloud-init should be just LP: #XXX [18:07] blackboxsw, great, I will address that ASAP. [18:11] Yeah, that's GitHub leaking. [18:12] When I install cloud-init on RHEL 5.7 it throws URL errors and then fails: [18:12] 2019-09-06 14:42:28,584 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: url error [[Errno 113] No route to host] [18:13] In /etc/rc.d/init.d/cloud-init I see it trying to read /etc/sysconfig/cloud-init which doesn't exist [18:13] does that mean I screwed up the install? [18:13] ozzzo: Where did you install it from? [18:13] epel [18:14] rpm -ivh /u/yesuv/Downloads/epel-release-5-4.noarch.rpm [18:14] yum install -y cloud-init [18:15] ozzzo: What does `cloud-init --version` give you? [18:15] [root@image-qscl-rh57 sysconfig]# cloud-init --version [18:15] bad command --version. use one of ('start', 'start-local') [18:17] OK, I think that means that's an ooold version of cloud-init (which probably isn't a surprise in RHEL 5! :). [18:17] yeah even 0.7.9 has a cloud-init --version command :/ [18:18] is 5.7 too old to run cloud-init? [18:19] we're being asked to provide 5.7 VMs to save developers from having to upgrade their code [18:20] The honest answer from me is that I'm not sure. [18:21] What problem is it reporting? Does cloud-init require some kind of support service that works across the 169 network? [18:22] can I fix it by setting up something to answer the metadata request? [18:22] Well, it's trying to talk to the Amazon EC2 metadata servers, and not able to route to them. [18:23] But, honestly, the version you're running is so old that I don't know what else is supported. [18:23] ozzzo: if you are trying to buildimages might want to look at building or installing the latest cloud-init RPMs in https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/ but yeah per Odd_Bloke's comment, your image isn't contacting Ec2 urls for some reason [18:23] I suspect it's missing networking config in the image; you could try our cloud-init in the el-stable copr repo, [18:23] blackboxsw: I think for RHEL5.x they might need the older release [18:23] Yeah, I think RHEL5 is Py 2.4 or Py 2.5. [18:23] as in pre-py26? [18:23] wow [18:23] I'm not in AWS; is this early version of cloud-init designed to only work in AWS? [18:24] that's known to work on Centos6; might be old enough, but have the networking features needed to bring up network for an ec2 crawl [18:24] we're setting up openstack VM images [18:24] ozzzo: no, there are many datasources, openstack also uses the same metadata URL [18:24] I suspect that the image doesn't have any build-in network config (like a /etc/sysconfig/network-scripts/ifcfg-eth0 which is configured to dhcp); [18:24] I don't think I can reach a 169 IP across the internet; that network doesn't route [18:25] it seems like I would need a server on my local network to answer that request [18:25] and so cloud-init will try to talk (over network) to different endpoints to determine if it's running on a particular cloud type [18:25] there are other datasources, like NoCloud which can use a localally attached disk with configuration in it [18:26] so I can setup nocloud and then configure cloud-init to use that instead of 169? [18:27] yes, https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html [18:27] Well, in an OpenStack cloud there should still be something on 169.254.169.254, right? [18:27] Or it should be using ConfigDrive. [18:27] I suspect ozzzo is booting outside of the cloud [18:27] ozzzo: Are you testing your images in the environment you expect them to run, or just locally? [18:27] to test the image , is that right ? [18:27] This is a VM image; I'm just building it [18:28] yes, in the VM environment, there may be something listening on 169 [18:28] we're building the images on VMWare [18:30] you may find that the image will work fine inside the openstack environment; testing your local imge with NoCloud is a reasonable first step to see if cloud-init you put in the image is working. [18:30] ok I'll try it, thanks for the advice [18:32] Odd_Bloke: blackboxsw: I can't sort out why the autoland is failing on pycodestyle ... thoughts? https://jenkins.ubuntu.com/server/job/cloud-init-autoland-test/315/console [18:33] I've run tox and tox -e tip-pycodestyle with no issues; it's complaining about 3 new lines where there should be two, but the file in the repo is good to go [18:44] Yeah, I can't see why either. [18:53] rharper: Are you on bionic? [18:53] (I'm wondering if it's a Py 3.6 issue?) [18:53] no, xenial [18:53] but I can try on bionic [19:06] we're running cloud-init 0.6.3-0.12.bzr532.el5 [19:07] I'm going to try ignoring the cloud-init error on the image, finish building it, and then build OS VMs to see if cloud-init works there [20:01] Odd_Bloke: I needed to rebase, now I see it and removing the extra line, force push should fix here shortly [20:06] \o/ [20:06] So the extra line was showing up in the merge commit? [20:07] yes [20:07] I didn't realize I was not rebased to tip [20:08] Wow, good job on finding that. [20:09] I think I'd just be unconscious from banging my head on things. [20:10] I was for a bit in a bionic container [20:10] but now I've got a bitter headache in #curtin [20:10] *sigh* [20:10] bigger (and bitter) [20:54] blackboxsw: ok, I re-approved my netfailover branch after the force push, hoping that the autolander will be happy now