=== tds3 is now known as tds | ||
Odd_Bloke | Ooh, OK, I had convinced myself it was only CentOS, thanks for that! | 14:23 |
---|---|---|
Odd_Bloke | blackboxsw: falcojr: Should we disable the stale bot for the break? ~Everything will get closed out otherwise, I suspect. | 14:31 |
meena | given the amount of crap in that pr of mine that just got closed, i might just open a fresh one | 14:37 |
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 | 14:44 |
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:26 |
falcojr | cool, I'll jump to it | 15:27 |
falcojr | I'll add a reminder to my calendar to turn the check back on ;) | 15:43 |
Odd_Bloke | I've also added a snoozed card on our Trello board, so hopefully between all that we'll remember. :) | 15:49 |
Odd_Bloke | Hmm, looks like stale is going to error every time now, will fix that. | 17:36 |
Odd_Bloke | blackboxsw: falcojr: https://github.com/canonical/cloud-init/pull/740 | 17:42 |
Odd_Bloke | falcojr: I see a new commit pushed to #738, but the name of the Travis job still includes "WIP". | 18:30 |
falcojr | ah, sorry...thought you were referring to the PR itself, not the name | 19:05 |
Odd_Bloke | Yep, I could have made that more obvious! | 19:12 |
Odd_Bloke | Thanks! | 19:12 |
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:26 |
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:27 |
blackboxsw | d'oh PEBChadAndKeyboard | 19:28 |
Odd_Bloke | ^_^ | 19:28 |
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:29 |
Odd_Bloke | Hah. | 19:32 |
Odd_Bloke | I did notice "19.4" and wonder. | 19:32 |
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:40 |
Odd_Bloke | blackboxsw: Sold. | 19:49 |
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:51 |
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 | 19:52 |
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:10 |
hggdh | solves the problem. | 21:11 |
hggdh | (seen on RHEL 7.8 and 7.9, and OEL 7.8. Probably also affects CentOS 7.[89] | 21:12 |
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:48 |
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. | 21:58 |
=== 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 | ||
Otanaut | powersj: ah ok but baked as in "installed" is enough, right? | 22:40 |
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:49 |
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;` | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!