[03:21] <htaccess> are there any other docs about https://cloudinit.readthedocs.io/en/latest/topics/examples.html#adding-a-yum-repository besides this? I want to know if i can point gpgkey: at a url rather than a file
[03:32] <htaccess> found it here https://www.zetta.io/en/help/articles-tutorials/cloud-init-reference/
[10:26] <TJ-> I'm trying to diagnose why a Vagrant ubuntu/bionic64 image isn't accessing the userdata in the 2nd box, and I can't find any docs on how that is expected to happen. /run/cloud-init/cloud-init-generator.log reports "...enabled but no datasource found, disabling"
[11:22] <TJ-> OK, seems that vagrant-libvirt is setting the wrong disk type ('raw' instead of 'qcow2').
[14:44] <otubo> Hey guys, any plans to have a NetworkManeger renderer for cloud-init in a near future?
[14:49] <dpb1>  netplan can render to nm
[14:49] <TJ-> otubo: the cloud-init package (on Ubuntu 18.04) has a NM hook
[14:50] <dpb1> read here: https://cloudinit.readthedocs.io/en/latest/topics/network-config.html
[14:50] <TJ-> otubo: I see /etc/NetworkManager/dispatcher.d/hook-network-manager in the cloud-init package
[14:51] <otubo> dpb1: TJ- thanks I'll take a look
[15:59] <powersj> o/
[16:04] <blackboxsw> #startmeeting Cloud-init bi-weekly status meeting
[16:04] <meetingology> Meeting started Mon Aug  6 16:04:05 2018 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:04] <meetingology> Available commands: action commands idea info link nick
[16:04] <dpb1> o/
[16:04] <blackboxsw> hi folks, let's kickoff another cloud-init status meeting. Welcome back. Lot's of summer vacations disrupting our typical meeting schedule.
[16:05] <blackboxsw> Our last meeting's minutes should be up on our github site
[16:05] <blackboxsw> #link https://cloud-init.github.io/
[16:07] <blackboxsw> for this meeting we'll go through the following topics: previous actions, recent work, in-progress development and office hours
[16:09] <blackboxsw> #topic Previous Actions
[16:09] <blackboxsw> from our last meeting we had a couple of actions to carry over
[16:10] <blackboxsw> we landed the folowing branch which added support for a datasource to re-write network config across each boot.  https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348000
[16:10] <blackboxsw> #action rharper: and I need to review https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904
[16:10] <meetingology> ACTION: rharper: and I need to review https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904
[16:10] <blackboxsw> the above is still a carryover
[16:11] <blackboxsw> that's all for actions from last meeting
[16:11] <blackboxsw> #topic Recent Changes
[16:12] <blackboxsw> the following has landed in cloud-init tip:
[16:13] <blackboxsw> * oracle: fix detect_openstack to report True on OracleCloud.com DMI data (LP: #1784685)
[16:13] <blackboxsw> * tests: improve LXDInstance trying to workaround or catch bug.*
[16:13] <blackboxsw> * update_metadata re-config on every boot comments and tests not quite right [Mike Gerdts]
[16:13] <blackboxsw> * docs: note in rtd about avoiding /tmp when writing files
[16:13] <blackboxsw> * ubuntu,centos,debian: get_linux_distro to align with platform.dist
[16:13] <blackboxsw> * Fix boothook docs on environment variable name (INSTANCE_I -> INSTANCE_ID) (Marc Tamsky)
[16:13] <blackboxsw> * update_metadata: a datasource can support network re-config every boot
[16:13] <blackboxsw> * tests: drop salt-minion integration test
[16:13] <blackboxsw> * Retry on failed import of gpg receive keys.
[16:13] <blackboxsw> * tools: Fix run-container when neither source or binary package requested.
[16:13] <blackboxsw> * docs: Fix a small spelling error (Oz N Tiram)
[16:13] <blackboxsw> * tox: use simplestreams from git repository rather than bzr.
[16:14] <blackboxsw> generally speaking we had been spending some cycles on a stable release update (SRU) for cloud-init into Xenial and Bionic with top of tree cloud-init.
[16:15] <blackboxsw> notably, we discovered a potential regression in Oracle datasource detection of their OpenStack implementation so that fix is queued for publish into xenial and bionic
[16:15] <blackboxsw> 18.3-9 is what folks are looking for. in xenial/bionic/cosmic for latest cloud-init containing all the above fixes
[16:16] <blackboxsw> Also powersj has been working on an auto-lander for cloud-init branches to get a few of us out of the way once a branch hits acceptm
[16:16] <blackboxsw> Also powersj has been working on an auto-lander for cloud-init branches to get a few of us out of the way once a branch hits "Approved" status.
[16:16] <blackboxsw> #link https://jenkins.ubuntu.com/server/job/admin-lp-git-autoland/
[16:16] <powersj> yep that is live and with a recent fix to remove the extra "Author" line now
[16:16] <powersj> hopefully it is saving blackboxsw, smoser, and rharper time ;)
[16:17] <blackboxsw> powersj: can you explain what it does (so I don't have to type)
[16:17] <blackboxsw> :)
[16:17] <powersj> If a merge request is put in the "Approved" state, it will get test merged with the master branch
[16:17] <powersj> the tests will run the same as during a review and verify that it can merge cleanly
[16:18] <powersj> the commit message will get linted to verify it fits our format
[16:18] <powersj> and if everything looks good, get merged in and pushed to master
[16:18] <blackboxsw> thanks for that work powersj. it looks/works great so far.
[16:19] <blackboxsw> #topic In-progress Development
[16:19] <blackboxsw> All our current work is visible at the following trello board
[16:19] <blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
[16:20] <blackboxsw> I expect we'll have a couple of branches landed shortly in the following areas:
[16:21] <blackboxsw> - smoser is working: A datasource specific to Oracle, because of their specific implementation of Openstack. Oracle will no longer use just stock DataSourceOpenStack.
[16:21] <blackboxsw> - I
[16:21] <blackboxsw> - I'm trying to wrap up a branch for Azure to write network data from their IMDS per-boot
[16:22] <blackboxsw> #link https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348704
[16:22] <blackboxsw> - Joyent (SmartOS) per-boot network config review
[16:23] <blackboxsw>   - a couple netplan config option bugs for bionic ++
[16:24] <blackboxsw> - and standardize instance-data sourcing in #cloud-config files (like referencing the hostname as detected from instance metadata)
[16:24] <blackboxsw> I think that probably wraps it up for stuff in progress
[16:24] <blackboxsw> anything I'm missing?
[16:25] <blackboxsw> ... without further ado
[16:25] <blackboxsw> #topic Office Hource (next ~30 mins)
[16:26] <blackboxsw> eyes will float on this channel for any bug/feature discussions, review requests  etc. any cloud-init topic is acceptable.
[16:28] <blackboxsw> a number of us are going to be prepping for a cloud-init summit meeting in the weeks to come.  A number of attendees from various vendors and clouds are attending as well to do a bit of planning on what cloud-init should look like next year. If folks get a chance, think about any feature or topic suggestions that would benefit cloud-init users and we'll see if we can discuss them at the summit.
[16:31] <blackboxsw> while I'm at it, I think I'll set the topic to next status meeting time so folks know it's coming.
[16:39] <blackboxsw> also just noticed the following branch, which admitedly is a bit stale, but adds hyperv logging via kvp. kinda cool for stuffing data into the registry on windows vms. Might have to get a review on that before the next status meeting.
[16:39] <blackboxsw> #link https://code.launchpad.net/~andyliuliming/cloud-init/+git/cloud-init/+merge/351742.
[16:39] <blackboxsw> it looks a bit noisy on the debug front with adding out/err messages for all subp calls, but other than that fairly straight forward.
[17:03] <blackboxsw> looks like that's a wrap for today.
[17:03] <blackboxsw> #link https://cloud-init.github.io   for meeting minutes
[17:04] <blackboxsw> see you next time: 2 weeks from today
[17:04] <blackboxsw> #endmeeting
[17:04] <meetingology> Meeting ended Mon Aug  6 17:04:11 2018 UTC.
[17:04] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-08-06-16.04.moin.txt
[18:11] <blackboxsw> smoser: I'm not quite sure how to handle your comments that DataSourceAzure._is_platform_viable should be a separate function in the Azure module. Ultimately, what I want is for get_data to call _is_platform_viable  prior to re-running the private _get_data on a given datasource instance. If we separate it out to only a module function instead of a class method, then we may have to deal with importing the right function
[18:11] <blackboxsw> per module in the DataSource parent class when running get_data().   I could see wrapping the module function as a classmethod so we have that class method available to us when we are operating on the DataSource.get_data() call of _is_platform_viable. Having the separate module function does ease testability without all the other datasource setup required so I'm +1 on the approach: separate function plus
[18:11] <blackboxsw> DataSource._is_platform_viable.
[18:13] <blackboxsw> Long term, I want all datasources to have an is_platform_viable publc method we can call to quick-check DMI/SMBIOS/environment for 'maybe' before attempting to walk metadata services (because that costs more). is_platform_viable would only do the quick sniff/test ds-identify(cloud-id) does and exit False if known not-compatible
[18:14] <blackboxsw> if we surface that method as a public class method, we can also easily test if via CLI to ensure platform changes didn't break cloud-init python datasource detection
[18:37] <smoser> blackboxsw: having all datasources have a 'is_platform_viable' is a reasonable goal for sure.
[18:38] <smoser> i was just suggesting that that method is either a @classmethod
[18:38] <smoser> and/or it simply (for ease of test) wraps a _is_platform_viable
[18:38] <smoser> in the .py file
[19:30] <blackboxsw> +1 smoser thanks. so you don't like side-effect in Azure.network_config to remove cpc image netplan yaml. I tend to agree, what since get_data has side-effects, and needs to be run before network_config anyway, why not do maybe_remove_ubuntu_network_config_scripts
[19:30] <blackboxsw> after we detect we are on azure
[19:31] <blackboxsw> wow thinkos.   maybe_remove_ubuntu_network_config_scripts from network_config -> _get_data
[19:32] <smoser> is DataSource.activate too late ?
[19:32] <blackboxsw> checking,
[19:33] <blackboxsw> I think that should be good
[21:31] <blackboxsw> bah wrong, ok can't do it at activate timeframe as we are attempting to generate network config in init-local, ds.activate doesn't happen until init stage.  So, we'd have collisions with cloud-init's netplan from IMDS and /etc/netplan/90-hotplug-azure.yaml
[21:31] <blackboxsw> which we are trying to remove
[21:31] <blackboxsw> during network-config generation
[21:34] <blackboxsw> ok I'll move it to _get_data and out of network config at least. But not sure where a better home would be for this call.