[11:13] <Xat`> hello guys !
[11:17] <Xat`> cloud-init erases /etc/ssh/ssh_host_*_key file when it starts
[11:18] <Xat`> I don't want this behavior, how can I remove this ?
[11:35] <meena> Xat`: hello
[11:36] <meena> generally, it shouldn't erase, but (re)create them. and it should only recreate them if something really signifcant has changed about the server
[13:24] <Xat`> meena: I have a 2 SFTP servers behind a load balancer. When sftp client are connecting to the loadbalancer endpoint, they are "forwarded" to one of the two servers. Because of that, sftp client spawns a security alert because ssh fingerprint has changed. This is why I tried to setup host keys from /etc/ssh/ directory.
[13:25] <Xat`> But, cloud-init erases them in the 'init' phase
[13:26] <meena> Xat`: ooookay. so, you might wanna disable that module
[13:26] <Xat`> yeah :) Can I have a list of module or get doc related to specific module
[13:26] <meena> https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl#L75
[13:27] <meena> and then there's this: https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl#L85
[13:27] <Xat`> I guess ssh-authkey-fingerprints could be good one
[13:28] <meena> i dunno all of them, i keep ssh to a bare minimum
[13:29] <meena> buuuuuuut now i'm wondering if i shouldn't be using cloud-init to roll out my git deploy key >_>
[13:29] <Xat`> :)
[14:20] <Odd_Bloke> Xat`: How are the SSH host keys getting generated on the host (if not by cloud-init at boot)?
[15:21] <Xat`> Odd_Bloke: using an ansible role
[15:22] <Xat`> I am using a lot of ansible stuff, but it seems that cloud-init could help me for some things
[15:23] <Odd_Bloke> Xat`: OK, sounds like it is sensible to disable the SSH key behaviour then.  For _some_ reason, that specific part of the docs isn't rendering at the moment, here's an older version where it _is_ rendered: https://cloudinit.readthedocs.io/en/19.2/topics/modules.html#ssh
[15:23] <Odd_Bloke> You probably want `ssh_deletekeys: False` in your user data.
[15:24] <Xat`> I was not at all aware about it. But now I know I have to deal with it ;)
[15:24] <Odd_Bloke> ^_^
[15:24] <Xat`> Odd_Bloke: yes, I did it
[15:24] <Xat`> in combination with ssh_genkeytypes: []
[15:25] <Odd_Bloke> And did that address your issues, or are you still seeing some behaviour you don't want?
[15:25] <Xat`> Odd_Bloke: my issue is now solved ;)
[15:26] <Xat`> I have to set both
[15:26] <Xat`> thank you guys Odd_Bloke & meena
[15:26] <Odd_Bloke> Yeah, I was going to point at ssh_genkeytypes next. :)
[15:26] <Odd_Bloke> Glad to hear it's resolved! :)
[15:26] <Xat`> :)
[15:29] <akik> Odd_Bloke: does a list of all the cloud-init tasks default exist somewhere?
[15:29] <akik> default tasks
[15:29] <Odd_Bloke> akik: Can you expand on what you mean by "tasks"?
[15:30] <akik> Odd_Bloke: for example that default user creation
[15:30] <akik> and that ssh_deletekeys
[15:32] <Xat`> akik: I was actually looking for the same doc
[15:32] <Xat`> but I used the code instead
[15:33] <Odd_Bloke> akik: So there is some stuff that cloud-init does on a per-platform basis (e.g. it will mount a drive to read configuration for ConfigDrive, it will do some specific networking stuff on Azure, etc.) and everything else is contained in config modules which are documented at https://cloudinit.readthedocs.io/en/latest/topics/modules.html
[15:33] <akik> i'd like cloud-init to be very clear on what it'll do by default
[15:34] <akik> Odd_Bloke: which ones are ran by default?
[15:34] <Odd_Bloke> Which modules run is entirely configurable per-system, so there isn't an explicit list that upstream can give you for your particular system.
[15:35] <Odd_Bloke> But you can see the configuration template that upstream ship here: https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl
[15:35] <akik> what's upstream in this case?
[15:35] <akik> ubuntu?
[15:35] <Odd_Bloke> No, cloud-init.
[15:36] <Odd_Bloke> You can look at /etc/cloud/cloud.cfg to see what your system is configured to do.
[15:36] <akik> for example i removed the user creation from my user-data, and got that default centos user. that was totally unexpected
[15:38] <Odd_Bloke> Right, that's how the CentOS packages configure cloud-init.
[15:38] <Odd_Bloke> (And almost all distros do the same, including Ubuntu.)
[15:38] <akik> i don't remember if it added NOPASSWD: to sudo config
[15:39] <akik> that shouldn't happen
[15:42] <Odd_Bloke> How would you set the password in the default case that no user-data is passed?
[16:56] <Odd_Bloke> blackboxsw: LMAO, GitHub just didn't attach my comments to the right lines at all.
[16:56] <blackboxsw> yeah that was strange
[16:56] <Odd_Bloke> blackboxsw: Search for "1min"
[16:58] <blackboxsw> found it Odd_Bloke thanks. That system had a 1 min execution on the cmd ssh-import-id chad.smith :).   I'm reattempting a complex azure network run to see if it hit the same issue
[17:09] <Odd_Bloke> OK, thanks!
[17:10] <Odd_Bloke> blackboxsw: If you're looking for a break: https://github.com/canonical/cloud-init/pull/178
[17:42] <blackboxsw> #startmeeting Cloud-init bi-weekly status
[17:42] <meetingology> Meeting started Tue Jan 21 17:42:43 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:42] <meetingology> Available commands: action commands idea info link nick
[17:43] <blackboxsw> At long last, and a bit late. Time for a brief cloud-init status meeting
[17:43] <blackboxsw> Coud-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.
[17:44] <blackboxsw> You can always find the next date and time of the cloud-init status meeting in the topic of this channel.
[17:45] <blackboxsw> it also serves as a reminder to me that we need to start it as I find it's easy to forget the appointment if it isn't staring us in the face.
[17:46] <blackboxsw> Let's set next meeting now
=== blackboxsw changed the topic of #cloud-init to:   cloud-init pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting February 4 17:15 UTC | 19.4 (Dec 17) drops Py2.7 : origin/stable-19.4 | 20.1 (Feb 18) | https://bugs.launchpad.net/cloud-init/+filebug
[17:48] <blackboxsw> our previous meeting minutes are recorded on our  github site
[17:49] <blackboxsw> #link https://cloud-init.github.io/
[17:49] <blackboxsw> the topics we cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Upcoming Meetings, Office Hours (~30 mins).
[17:50] <blackboxsw> #topic Previous Actions
[17:50] <blackboxsw> Previous  #ACTION bbsw seed initial community charter bitesize bugs   ... DONE.
[17:51] <blackboxsw> 'bitesize' bugs for cloud-init can be found at the following link
[17:51] <blackboxsw> #link bugs.launchpad.net/cloud-init/+bugs?field.tag=bitesize
[17:52] <blackboxsw> These bugs should be easy to work in parallel as well as self-contained bits of work that any member of the community could approach as a small chunk of work
[17:53] <blackboxsw> we moved from using trello board for tracking these tasks to using launchpad bugs as it eases the ability to search and grab ownership of the specific features/bugs
[17:53] <blackboxsw> #topic Recent Changes
[17:55] <blackboxsw> The following commits landed in tip of master: (found by git log --since 01/07/2020)
[17:55] <blackboxsw>     - Add Rootbox & HyperOne to list of cloud in README (#176) [Adam Dobrawy]
[17:55] <blackboxsw>     - docs: add proposed SRU testing procedure (#167)
[17:55] <blackboxsw>     - util: rename get_architecture to get_dpkg_architecture (#173)
[17:55] <blackboxsw>     - Ensure util.get_architecture() runs only once (#172)
[17:55] <blackboxsw>     - Only use gpart if it is the BSD gpart (#131) [Conrad Hoffmann]
[17:55] <blackboxsw>     - freebsd: remove superflu exception mapping (#166) [Gonéri Le Bouder]
[17:55] <blackboxsw>     - ssh_auth_key_fingerprints_disable test: fix capitalization (#165)
[17:55] <blackboxsw>       [Paride Legovini]
[17:55] <blackboxsw>     - util: move uptime's else branch into its own boottime function (#53)
[17:55] <blackboxsw>       [Igor Galić] (LP: #1853160)
[17:55] <blackboxsw>     - workflows: add contributor license agreement checker (#155)
[17:55] <blackboxsw>     - net: fix rendering of 'static6' in network config (#77) (LP: #1850988)
[17:55] <blackboxsw>     - Make tests work with Python 3.8 (#139) [Conrad Hoffmann]
[17:55] <blackboxsw>     - fixed minor bug with mkswap in cc_disk_setup.py (#143) [andreaf74]
[17:55] <ubot5> Launchpad bug 1853160 in cloud-init "uptime code does not work on FreeBSD with python 3" [Medium,Fix committed] https://launchpad.net/bugs/1853160
[17:55] <ubot5> Launchpad bug 1850988 in cloud-init "[Cloud-init 18.5][CentOS 7 on vSphere] Crash when configuring static dual-stack (IPv4 + IPv6) networking" [Medium,Fix committed] https://launchpad.net/bugs/1850988
[17:56] <blackboxsw> Thanks Adam, Conrad, andreaf74, Gonéri and meena for improving cloud-init.
[17:57] <blackboxsw> #topic In-progress Development
[17:58] <blackboxsw> FreeBSD, NetBSD improvements are under heavy development, thanks meena and Goneri for all the PRs put of in that regard.
[17:58] <blackboxsw> Also robjo has started work on cleanup of sysconfig net rendering per https://github.com/canonical/cloud-init/pull/162 and a mailing list discussion
[17:59] <blackboxsw> rharper is also midstream on "cloud-init run as a daemon" mode https://github.com/canonical/cloud-init/pull/48   which should improve cloud-init startup times by avoiding having to reload python 4 times for each cloud-init stage
[18:00] <blackboxsw> Also in progress, upstream has started to SRU testing for cloud-init 19.4.33 into Ubuntu Xenial, Bionic and Eoan.
[18:01] <blackboxsw> We expect to wrap up that testing this week for a publish of cloud-init 19.4.33 to those series
[18:02] <blackboxsw> #topic Community Charter
[18:02] <blackboxsw> As a note, any community member is welcome to participate in SRU testing of cloud-init if those changesets in the SRU affect your cloud platform or features.
[18:02] <blackboxsw> We have added a guide for SRU testing on Ubuntu here
[18:03] <tribaal> duly noted :)
[18:03] <blackboxsw> #link https://cloudinit.readthedocs.io/en/latest/topics/debugging.html#manual-sru-verification-procedure
[18:03] <blackboxsw> :)
[18:04] <blackboxsw> ahh tribaal we should pull in your PR for manual testing of Exoscale too if you think it's ready https://github.com/cloud-init/ubuntu-sru/pull/64
[18:04] <tribaal> it's not unfortunately :/
[18:05] <blackboxsw> ahh, ok *good*, thought it was waiting on review
[18:05] <blackboxsw> ok can table that for another SRU (which will be around Feb 14th likely)
[18:06] <tribaal> no worries, happy to help test the current one anyway
[18:06] <blackboxsw> community notice: we are targeting Feb 18th as our cutoff for upstream cloud-init version 20.1 (which will be SRU'd to Ubuntu Xenial, bionic and Eoan). If there are features  of bug fixes that you'd like to get into cloud-init 20.1 please raise them as PRs or discussion on the mailinglist or in channel
[18:08] <blackboxsw> #topic Office Hours (next ~30 mins)
[18:08] <blackboxsw> This time is spent on any cloud-init feature/bug/branch discussions. quetions or concerns and topics are welcome. In the absence of topics we'll groom the review queue.
[18:09] <blackboxsw> I'm wrapping up some significant change suggestions the networking stuff for sysconfig on https://github.com/canonical/cloud-init/pull/162
[18:10] <blackboxsw> I should have that review done in about an hour
[18:10] <blackboxsw> I've added myself as the "assignee" to that PR to indicate it as priority for me
[18:11] <blackboxsw> also, note in SRU testing  I've run into a repeated issue with cloud-init's ssh-import-id  taking 1 minute to import a single ssh pubkey on Azure bionic advanced networking vms. (2 nics + ipv6 + multiple IPs).  I'll be debugging this a bit today to make sure it is not a regression for this cloud-init SRU 19.4.33
[18:12] <blackboxsw> if anyone has any feedback or issues associated with this cloud-init v 19.4.33 SRU, they can comment on the SRU bug or raise a new bug or comment in IRC
[18:12] <blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1859725
[18:12] <ubot5> Ubuntu bug 1859725 in cloud-init (Ubuntu) "sru cloud-init (19.3.41 to 19.4.33) Xenial, Bionic and Eoan" [Undecided,New]
[18:55] <blackboxsw> ok, that about wraps today's status meeting. We'll have the next one February 4th to chat again about getting features ready for 20.1
[18:55] <blackboxsw> Thanks for tuning in.
[18:55] <blackboxsw> #endmeeting
[18:55] <meetingology> Meeting ended Tue Jan 21 18:55:32 2020 UTC.
[18:55] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-01-21-17.42.moin.txt
[19:17] <meena> how do i keep missing these meetings
[19:30] <blackboxsw> meena: it's ok, I nearly missed it too
[19:30] <blackboxsw> hrm Azure advanced vm still seeing the same 1 min issue on ssh-import-id.
[19:35] <blackboxsw> looks like the Azure vm with ipv6 is timing out on ipv6, then eventually falls back to ipv4. connect(3, {sa_family=AF_INET6, sin6_port=htons(443), inet_pton(AF_INET6, "2001:67c:1560:8003::8003", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ETIMEDOUT (Connection timed out)
[19:48] <blackboxsw> I need to check initial ip config there  vs the config post cloud-init upgrade rendered netplan is the same both prior to upgrade and afterward, yet prior to upgrade doesn't have the ipv6timeout
[20:42] <blackboxsw> probably a failure for me to create the right ipv6 config on the vm
[22:04] <blackboxsw> Odd_Bloke: approved https://github.com/canonical/cloud-init/pull/178#pullrequestreview-346223273   though I think we need to track somewhere (maybe just a trello card on the SRU template board?  to remove python-six from depends in ubuntu(xenial|bionic|eoan) debian/control branches during next SRU.
[22:09] <Odd_Bloke> blackboxsw: We're still a ways away from actually being rid of six, so it would be premature at this point.
[22:09] <Odd_Bloke> But I'll add a task to work that out before we can consider it Done.
[22:21] <meena> grep -wc six
[22:28] <meena> > but we need to make sure we drop python-six as a package dependency from ubuntu/xenial|bionic|eoan debian/control files.
[22:28] <meena> oy, i thought six was a builtin
[22:32] <Odd_Bloke> Nope, but it is a single file drop-in, pretty much.
[22:53] <Odd_Bloke> blackboxsw: If you need a break, more six removal: https://github.com/canonical/cloud-init/pull/179
[22:54] <blackboxsw> yeah, I'm basically in azure cli ipv6 setup issues for manual sru testing so it's a 15 min downtime while awaiting the deployment run to discover that I misconfigured ipv6 routing network security groups