holmanbcaribou: poking at NetworkManager and systemd-networkd configs they both seem to have support for directly connected gateways (no surprise there, given the netplan config setting). It sounds like both of those renderers and per klnikita's comment also debian's eni renderer should be able to support this - just requires a bit of plumbing (I think)00:34
Dev040Hello Guys!11:00
Dev040I'm trying to use write_files.11:00
Dev040write_files is trying to write into a file which depends on a mount.11:00
Dev040What is the order of cloudinit? Is write_files executed before mounts?11:00
Dev040If so, how to handle this problem I have?11:00
acibaDev040: Hello11:04
acibato see the modules order you can execute `cloud-init query merged_cfg`11:05
acibathere you can see what modules run in what stage (https://cloudinit.readthedocs.io/en/latest/topics/boot.html)11:06
aciba`write_files` and mount run tipically in the init stage11:07
acibabut there is an option to defer `write_files` and execute it in the final stage: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#write-files11:07
acibadefer: true in the file object under write_files, see the examples in the previous link11:09
acibaExample5 more concretely11:09
meenaaciba: how do i access a defaultdict? and was this way of building it: https://github.com/canonical/cloud-init/compare/main...igalic:cloud-init:bsd/fix_duplicate_macs even sensible?11:25
meenaI mean, good morning11:25
acibameena: morning one can access a defaultdict as a normal dict, but one cannot distinguish between already added key and not added. IN typically convert the defaultdicts to dicts after they are built to be able to do so.11:30
acibaI think that's sensible :)11:30
meenaaciba: the documentation seems a bit thin: https://docs.python.org/3/library/collections.html#collections.defaultdict how do I convert it?11:41
meenaoh, you just say: dict(your_default_dict)11:43
meenathat'll instantly fix like 14 failing test cases11:44
meenanope, doesn't, cuz I'm still building lists for this…11:50
acibaconvert to dict while reading and convert to defaultdict while writing ?11:55
acibameena: if a lot of conversions are expected, one can modify my_default_dict.default_factory attibute instead of converting to/from dict https://docs.python.org/3/library/collections.html#collections.defaultdict.default_factory11:57
meenaaciba: my plan is to only use it for building, because it seems easier…11:58
Dev040aciba write_files with defer worked great!12:09
Dev040How does write_files work? Does it override existing files or doesnt do anything when the given path already exists?12:09
acibaDev040: nice to here that. That's not defined in the docs. By a quick look to the code, it looks like it does override existing files.12:13
acibahear *12:13
acibaPR up clarifying that: https://github.com/canonical/cloud-init/pull/191612:22
-ubottu:#cloud-init- Pull 1916 in canonical/cloud-init "doc: improve cc_write_files doc" [Open]12:22
meenathat was … actually pretty easy12:24
meenaaciba ^ cjp256 ^12:24
meenaI should add some tests for this case…12:25
cjp256awesome :D12:25
acibanice :)12:25
meenaI think my target will be to refactor get_interfaces() and get_interfaces_by_mac()… before the end of the year :P12:27
meena(*or fiscal year, maybe whenever that is)12:27
meenaso the fact that get_interfaces() is currently broken on BSD for at least Azure compels me to hurry up with this12:28
ahasenackhi, does "cloud-init status --wait" block forever?12:33
meenaahasenack: if it does, something must be broken.12:35
ahasenackI'm considering wrapping a call to it in timeout(1)12:35
meenaahasenack: there has to be a reason why it's blocking forever. What's the logs say?12:37
acibaahasenack: it waits until the status is different from { running , not_run }12:37
ahasenackmeena: it's not blocking forever, I'm just guarding this script against that eventuality12:38
ahasenackso I was looking for docs on it, or maybe its own little --timeout parameter12:38
acibathe difficulty may be to define a default timeout suitable for every one. but we could probably introduce an optional flag to specify the timeout time as you suggest12:40
ahasenackblocking forever is usually a nono, that's my thought12:41
ahasenackthis is in a script that runs tests, so specially here I don't want forever blocks12:41
acibaI agree with you12:45
acibaI think the original intention of the --wait flag was to let others block until cloud-init finishes. But for a testing context, a supplemental --timeout makes completely sense.12:48
meenacjp256: https://github.com/canonical/cloud-init/pull/191713:02
-ubottu:#cloud-init- Pull 1917 in canonical/cloud-init "BSD: fix duplicate macs in Ifconfig parser" [Open]13:02
meenahow did i break the readthedocs build?13:21
falcojryou didn't. It's broken atm13:25
meenain that case, that's ready to review then, falcojr14:30
meenauuuh, I can do another assert, actually14:31
blackboxswmeena: you can git fetch upstream; git rebase -i upstream/main now to fix readthedocs CI. We just merged https://github.com/canonical/cloud-init/pull/191215:52
-ubottu:#cloud-init- Pull 1912 in canonical/cloud-init "read-version: When insufficient tags, use cloudinit.version.get_version" [Merged]15:52
seanbrighthi there. i am using the nocloud datasource and providing a static network configuration via the network-config file. i want to change the IP after first boot, so i've updated the network-config file and rebuilt the ISO and rebooted the VM but it doesn't re-render the netplan config when i do that. is there a way i can force that?15:52
blackboxswseanbright: typically datasourcenocloud renders network only PER_BOOT_NEW_INSTANCE. If you are rebuilding the ISO and want to trigger cloud-init to run everything again (including network config). You could change the 'instance-id: value'  in your meta-data file and that will indicate to cloud-init to re-run everything including network config. 15:58
seanbrightblackboxsw: perfect15:58
seanbrightblackboxsw: thank you!15:59
blackboxswseanbright: I'm trying to think through whether we can override the default_update_events https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/__init__.py#L224-L228  to include eventtype.BOOT for NoCloud datasource, but I'm not sure it's possible without code changes15:59
blackboxswseanbright: be wary the new instance-id: in metadata tells cloud-init to re-run everything including any user-data and SSH host key regeneration on the next boot. so the identity of your system in terms of SSH will change.16:00
meenablackboxsw: I used the GitHub sync button. but i still wanna add that yet, however, I'm away from the laptop until 18:4516:00
minimalblackboxsw: to be honest I'd assumed NoCloud network-config would always be a one-shot thing, never thought anyone would want to change/update it16:01
seanbrightblackboxsw: so maybe i am better off just manually updating the network config.16:02
blackboxswminimal: yes generally that should be the case. because it's not a cloud :) and shouldn't be changing metadata or config after that first boot. 16:02
blackboxswseanbright: if you are creating the iso yourself, it would be best to seed it with all the data you intend for final configuration16:03
minimalespecially in the scenario of using cloud-init for *physical* servers (which I use it for) as there's a security risk if someone sticks in a USB device with cidata and reboots (i.e. powers off/on) a machine to unexpectedly (for the "admin" person) reconfigure it16:03
seanbrightblackboxsw: sure. makes sense. thanks for your help.16:04
holmanbminimal: curious, which approach do you use to install cloud-init on the servers?17:45
holmanbone of the default modes from the alpine wiki? from a cloud image directly? something else?17:47
meenaholmanb: minimal is gone17:51
holmanbah, thanks17:52
meenasome people aren't on IRC 24/7. weirdos17:56
holmanbmy quassel server is always "on", but I'm not always "on"17:56
meenasame with my TheLounge17:57
meenaI used to run Quassel until i decided to consolidate my chat/social stuff into a Web server: https://igalic.co/thoughts/2020-05-30-social-apps-in-firefox.html17:58
holmanbanother vote for TheLounge :) - I keep hearing good things but haven't tried it17:58
holmanblooks nice17:58
meenathe Quassel Web interface(s?) at the time were pretty horrid17:59
meenaholmanb: he warned: there's currently zero full-time devs working on it17:59
holmanbI use the mobile/desktop apps, didn't even know a web client existed17:59
falcojrmeena: looks like we took a similar journey. I used franz and got frustrated with the same issues. I used the lounge until very recently and now have consolidated some of my chats into a matrix server18:00
holmanb+1 thx, after initial install, which was pretty painless, I've had zero issues (was initially on web clients then matrix for irc)18:00
holmanbthe UI isn't completely seemless on gnome, but it is a qt app iirc so to be expected I guess18:01
holmanbgnome UI isn't completely seemless on gnome either, so /shrug18:01
blackboxswholmanb: or falcojr I minor bump because my previous commit 'fixing read-version' for shallow git clones didn't drop a 2nd call to the git descibe HEAD --long. https://github.com/canonical/cloud-init/pull/191818:57
-ubottu:#cloud-init- Pull 1918 in canonical/cloud-init "tools: read-version drop extra call to git describe --long" [Open]18:57
blackboxswthis would be needed for any PRs which are failing RTD test runners18:57
blackboxswthx. I only recognized because my nocloud PR continued to fail after a git rebase18:58
holmanbblackboxsw: I think the RTD test runner issue should be resolved now. Are we seeing that still?19:04
blackboxswholmanb: the last test run failed on that 2nd line that I should have redacted line 10319:05
blackboxsweven through the failure happened on shallow clone it still fell through and re-ran the --long cmd19:05
holmanb I messaged a short bit ago in a different channel about that, I should have reflected that more broadly19:05
blackboxsw+1 that said, the changeset we landed before still has an ommission in that it'll still try to run --long twice on a shallow clone19:07
blackboxswStrange as the passing RTD CI builds for are still sing --depth 50... not sure why that is getting enough context for tags now. 19:10
blackboxswevent without the 'fix' in main https://readthedocs.com/projects/canonical-cloud-init/builds/1222922/19:10
holmanba couple of CI runs have made it through in the last day or so as well - I don't think this flakyness is new behavior19:13
blackboxswI only was able to get the RTD pass on https://github.com/canonical/cloud-init/pull/1879 after I rebased pulling in changes from 191819:14
-ubottu:#cloud-init- Pull 1879 in canonical/cloud-init "nocloud: add support for dmi variable expansion for seedfrom URL" [Open]19:14
blackboxswjust waiting on the final integration test to complete19:15
holmanbI still don't have visibility to see the RTD logs, but if anyone wants to check whether we are shallow cloning on new PRs I made a dummy: https://github.com/canonical/cloud-init/pull/191919:15
-ubottu:#cloud-init- Pull 1919 in canonical/cloud-init "ignoreme" [Open]19:15
blackboxsw@holmanb checking now19:15
blackboxswholmanb: woo hoo 19:15
blackboxswgit fetch origin --force --tags --prune --prune-tags pull/1919/head:external-191919:16
blackboxswno --depth19:16
blackboxswok that works for our project in general. that said, the read-version fixes are still 'valid' for shallow clone environments19:16
blackboxswin that we want to fallback to cloudinit.version if you can't see tags19:16
holmanb+1, thanks :)19:18
holmanbis there any reason we shouldn't try to eventually get RTD logs visible for non-members of the org?19:19
holmanbfor the driveby spelling fixers and whatnot19:19
blackboxswIt'd be nice if non-org members can see our CI failures and debug them themselves. I don't like the fact that our results are hidden behind firewalls 19:20
blackboxswI get it for or jenkins jobs as jenkins has a bad surface area for plugins and security breaches19:20
blackboxswbut anything we can make public we should19:20
holmanb+1 agreed19:21
minimalholmanb: Hi. You were looking me?23:51
minimalah, you were asking about how I install physical servers using cloud-init23:52
minimalI create a suitable disk image, using my own script: https://github.com/dermotbradley/create-alpine-disk-image23:53
minimalfor physical machines it has a small cidata partition with the YAML files23:53
minimalI boot the machines using USB, "dd" the disk image onto the HDD/SDD, edit the YAML files accordingly (e.g. set static IP etc in network-config.yaml) and then reboot the machine23:54
minimalI've been meaning to set up PXE for the same, rather than using a USB device23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!