=== tds3 is now known as tds
[14:23] <Odd_Bloke> Ooh, OK, I had convinced myself it was only CentOS, thanks for that!
[14:31] <Odd_Bloke> blackboxsw: falcojr: Should we disable the stale bot for the break?  ~Everything will get closed out otherwise, I suspect.
[14:37] <meena> given the amount of crap in that pr of mine that just got closed, i might just open a fresh one
[14:44] <Odd_Bloke> meena: So long as you retain a reference to the old one, so we can find older conversations, that's a reasonable approach. :)
[14:44] <Odd_Bloke> blackboxsw: falcojr: https://github.com/canonical/cloud-init/pull/735 <-- I think that'll do it, but let's chat at stand-up to confirm I'm not missing anything
[15:26] <Odd_Bloke> falcojr: blackboxsw: I've opened up a variety of PRs for bits and pieces that have occurred to me over the past couple of weeks, but I haven't had time for; all small: https://github.com/canonical/cloud-init/pull/733 https://github.com/canonical/cloud-init/pull/736 https://github.com/canonical/cloud-init/pull/737
[15:27] <falcojr> cool, I'll jump to it
[15:43] <falcojr> I'll add a reminder to my calendar to turn the check back on ;)
[15:49] <Odd_Bloke> I've also added a snoozed card on our Trello board, so hopefully between all that we'll remember. :)
[17:36] <Odd_Bloke> Hmm, looks like stale is going to error every time now, will fix that.
[17:42] <Odd_Bloke> blackboxsw: falcojr: https://github.com/canonical/cloud-init/pull/740
[18:30] <Odd_Bloke> falcojr: I see a new commit pushed to #738, but the name of the Travis job still includes "WIP".
[19:05] <falcojr> ah, sorry...thought you were referring to the PR itself, not the name
[19:12] <Odd_Bloke> Yep, I could have made that more obvious!
[19:12] <Odd_Bloke> Thanks!
[19:26] <blackboxsw> Odd_Bloke: I think I'm hitting this with latest `tox -e doc` on focal on your PR https://github.com/canonical/cloud-init/pull/739/files
[19:26] <blackboxsw> on master I don't this error: https://paste.ubuntu.com/p/WjND4KXjqs/   https://github.com/sphinx-doc/sphinx/issues/8400
[19:27] <blackboxsw> I'm looking more closely now. just wanted to reflect that issue to see if you hit that or whether you were in another build env
[19:27] <blackboxsw> ahh on master looks like Running Sphinx v1.8.5 o your brach Sphinx v.3.3.1
[19:27] <Odd_Bloke> blackboxsw: We're pinned at sphinx<2 in doc-requirements.txt.
[19:28] <blackboxsw> d'oh PEBChadAndKeyboard
[19:28] <Odd_Bloke> ^_^
[19:29] <blackboxsw> I had a local branch alias called oddbloke/doc that was conflicted with your PR
[19:29] <blackboxsw> turns out if you checkout a branch from Jan 2020. it doesn't behave the same way as your current PR
[19:32] <Odd_Bloke> Hah.
[19:32] <Odd_Bloke> I did notice "19.4" and wonder.
[19:40] <blackboxsw> Odd_Bloke: WDYT about renaming debugging and testing cloud-init topic in RTD to just "debugging cloud-init" as it is with your branch we now have 3 top-level topics that include "testing" in them
[19:49] <Odd_Bloke> blackboxsw: Sold.
[19:51] <blackboxsw> approved to the man in the yellow hat. awaiting CI
[19:51] <Odd_Bloke> blackboxsw: Are you logged in as the bot account? :p
[19:51] <blackboxsw> shoot
[19:51] <blackboxsw> ummmm... no why every would you say that :)
[19:52] <Odd_Bloke> I think it's preferable that it was you and not a rogue Jenkins job. :p
[19:52] <blackboxsw> true story. human blackboxsw just approved
[21:10] <hggdh> hi folks. customer has a NFSv3 mount in /etc/fstab. It seems cloud-init runs a 'mount -a' before the network is all set up and, as a result, VM fails to boot (gets stuck in network setup)
[21:10] <hggdh> changing cloud-init.service to state "After=network-online.target" and "Wants=network-online.target
[21:11] <hggdh>  solves the problem.
[21:12] <hggdh> (seen on RHEL 7.8 and 7.9, and OEL 7.8. Probably also affects CentOS 7.[89]
[21:48] <Otanaut> hey! i am trying to dive into cloud-init and i am not sure if i get it right: is cloud-init baked into debian? so i jsut throw my configuration into /etc/cloud/cloud.cfg.d/*.cfg and on first boot the system does it magic?
[21:58] <powersj> Otanaut, cloud-init is generally used when deploying a new cloud instance. Like on AWS, GCP, Azure. However it can also be used locally when deploying VMs. To use it, cloud-init needs to be baked into the image you are using.
=== powersj changed the topic of #cloud-init to: 20.4 (Nov 24) | file a bug: https://bugs.launchpad.net/cloud-init/+filebug | pull-requests: https://git.io/JeVed | meeting minutes: https://goo.gl/mrHdaj | next office hours: Jan 5 17:15 UTC
[22:40] <Otanaut> powersj: ah ok but baked as in "installed" is enough, right?
[22:49] <blackboxsw> Otanaut: yes that should be enough, most distro packaging of cloud-init installs the right startup scripts to make sure cloud-init runs properly during boot.
[22:53] <blackboxsw> it's testable with lxc if you have it: `lxc launch images:debian/buster deb-10; lxc exec deb-10 apt-get install cloud-init;`