[00:14] <meena> minimal: what, even, is dhcp6?
[00:15] <minimal> what do you mean? I've using a network-config v2 file
[00:16] <minimal> so "version: 2\nethernets:\n  eth0:\n    dhcp4:false\n    dhcp6: true\n
[00:19] <minimal> but cloud-init.log shows: stages.py[INFO]: Applying network configuration from ds bringup=False: {'version': 2, 'ethernets': {'eth0': {'dhcp4': True, 'dhcp6': True}}}
[00:21] <meena> I mean, what does dhcp6 do?
[00:21] <meena> ra?
[00:22] <minimal> it enables DHCPv6 support, that's not the issue though, I want to disable DHCPv4 support but it is somehow being overriden
[00:22] <minimal> meena: DHCPv6 would work together with RA, yes.........but that's not relevant to the issue
[00:35] <meena> oh, I didn't know there *is* DHCPv6
[00:36] <minimal> RFC 3315 from 2003
[00:52] <minimal> there is a cloud-init testcase for dhcpv6 only, but its using network-config v1, not v2, as input
[01:11] <blackboxsw> minimal: on Ubuntu, since we have netplan, v2 config is passed directly though to the renderer layer and written out to /etc/netplan/50-cloud-init.yaml for us. For non-netplan systems the network config gets converted to internal network_state and eventually rendered out to the network  backplane. Alpine linux is /etc/network/interfaces (ENI) right?
[01:12] <minimal> blackboxsw: figured it out - cidata ISO works as expected, eni file does not have dhcpv4 entry, however using same v2 network-config in a seed directory DHCPv4 *is* enabled - I guess its perhaps merging seed dir config with fallback somehow?
[01:13] <blackboxsw> minimal: right, each nocloud datasource meta-data is sourced with priority  and merged together if multiple sources are viable
[01:13] <minimal> right, but I was using only seed directory, no other source and the dhcp4: false was flipped to dhcp4: true
[01:14] <blackboxsw> ohh, hrm
[01:15] <minimal> separately, for network-config v2 still trying to work out to indicate non-static-IPv6, non-dhcpv6-~IPv6, e.g. slaac related, RA related stuff
[01:15] <minimal> i.e. in order to get "iface eth0 inet6 auto" in /e/n/i file
[01:16] <minimal> "dhcp6: true" gives me "iface eth0 inet6 dhcp" which is fine for DHCPv6
[01:16] <blackboxsw> hrm wondering what default could be generating that dhcp4: true.
[01:17] <minimal> that's why I wondered if somehow the "fallback" was being consulted
[01:18] <blackboxsw> It's possible in an image that network config could also be present in the image in /etc/cloud or /etc/cloud.cfg.d/*.cfg  which would pollute any other network config provided from other sources for nocloud
[01:18] <blackboxsw> but, I'm grasping at straws
[01:18] <minimal> not in my images ;-)
[01:19] <minimal> and the behaviour is different when I built an image with files in the seed directory vs with no such files but provided with cidata ISO at boot time
[01:25] <blackboxsw> DataSourceNoCloud::_merge_new_seed  looks like it will completely overwrite the entire network-config of the latest valid seed file it sees any network-config in a discovered nocloud viable source. So I don't see how it is getting a 'merge' of network-config from one source vs another here https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceNoCloud.py#L343
[01:26] <blackboxsw> it looks to me like last network-config present anywhere wins out in NoCloud
[01:27] <blackboxsw> which would be network-config file seen on CIDATA labeled device.
[01:28] <minimal> yeah, that's fine, the strangeness appeared when there was a CIDATA provided, only /var/lib/cloud/seed/nocloud/network-config
[01:29] <minimal> s/was a/was no/
[01:29] <blackboxsw> not sure offhand, and being pulled into the weekend vortex shortly :/
[01:30] <minimal> no problem, I'll have a look at it again myself
[01:31] <minimal> would welcome your thoughts on IPv6 network-config v2 settings in general (especially for eni rather than netplan) but we can chat about that next week
[01:32] <blackboxsw> +1 will mull that over .. this is related to "separately, for network-config v2 still trying to work out to indicate non-static-IPv6, non-dhcpv6-~IPv6, e.g. slaac related, RA related stuff" ?
[01:33] <minimal> yeah, I've used static IPv6 in the past fine, its all that other stuff and how to get eni with the right settings for it
[01:34] <blackboxsw> ok this is broader than me, but will refresh context a bit on it to see if I can think of something smart to say there
[01:34] <minimal> the testcases for this seem to only use v1 config
[01:40] <blackboxsw> yeah looking at commit history too in this space 62bbc262c3c7f633eac1d09ec78c055eef05166a and aa1014cae2e326109581d4624f3a195a89369fd7 makes me think there may be a gap there in v2. But I'll have to get more context there to be sure
[01:44] <minimal> I'll think up more work for you over the weekend ;-)


[07:26] <pavlushka> Good day Kilos :)
[15:09] <pavlushka> welcome zaki
[15:37] <pavlushka> Hello Tuhin :)
[15:37] <Tuhin> Hello
[15:38] <Tuhin> anyone here into electronics?
[15:38] <pavlushka> Tuhin: like?
[15:38] <Tuhin> like understanding circuits
[15:38] <Tuhin> where do i find BUET Electronics department people in IRC?
[15:41] <pavlushka> Tuhin: IRC is scarce in Bangladesh, the best you can have is an #electronics channel
[15:43] <pavlushka> Tuhin: or you can go there, www.bueteeearchives.net/
[15:48] <Tuhin> hm
[18:00] <pavlushka> Welcome back ahoneybun :)
[18:00] <pavlushka> hey dipraw !
[18:31] <ahoneybun> hey pavlushka
[18:34] <pavlushka> How it went ahoneybun ? your not being on IRC?
[18:35] <ahoneybun> pavlushka: it was fine with Telegram
[18:37] <pavlushka> ahoneybun: looks like it is :)
[18:38] <ahoneybun> pavlushka: so my server rebooted and I did not start the bouncer back up
[18:38] <ahoneybun> till today
[18:41] <pavlushka> ahoneybun: Its good that you are back finally by today :)
[18:41] <ahoneybun> ?
[18:42] <pavlushka> ah, hey walrider whats up?
[18:42] <walrider> ho asi
[18:42] <pavlushka> ahoneybun: I mean at least you started your bouncer today, not making further delay :)
[18:43] <pavlushka> walrider: ki korte aso meanwhile?
[18:43] <walrider> internee er kaj kam
[18:43] <pavlushka> any further delay
[18:43] <pavlushka> walrider: good
[18:44] <walrider> 16 nov internee shesh
[18:49] <walrider> :|
[18:58] <walrider> error
[18:58] <walrider> lol
[18:58] <pavlushka> walrider: its quick I guess
[18:59] <walrider> hm
[19:18] <pavlushka> good


[00:45] <habys> hey folks, when I add a key for a local package repository via the `user-data` file, it adds the key into /etc/trusted.gpg, which breaks attempting to run `apt update`. Has anyone else run into this?
[00:46] <habys> I'm thinking to work around it by putting the keys into /etc/trusted.d/source.gpg manually, but that is a lot more trouble than using the built-in `sources:` section in `user-data`.
[01:32] <holman> habys: How are you adding the key? Could you share a link to your user-data file?
[01:34] <holman> habys: What version of cloud-init are you on? There were some recent feature additions in the apt module around key handling.
[01:52] <habys> interesting, I will copy paste the relevant part in a sec
[01:53] <habys> I was just taking the down time to write a script to pull down new iso, kernel, and initrd for our ipxe environment
[01:53] <habys> I don't know the version of cloud-init, but the installer ISO was from 2022-11-03
[01:54] <habys> ah: /usr/bin/cloud-init 22.3.4-0ubuntu1~22.04.1
[01:58] <habys> here is what I hope is the relevant part of the config, here I am adding our local puppet mirror: https://termbin.com/rgfj
[01:59] <habys> oh heh, that's not local, but the idea is the same.
[02:49] <habys> I found my notes from setting this up manually, I would take the puppet repo key and put it in `/usr/share/keyrings/puppet7.gpg` then refer to it in `/etc/apt/sources.list.d/puppet7.list`: `deb [arch=amd64 signed-by=/usr/share/keyrings/puppet7.gpg] https://apt.puppetlabs.com jammy puppet`
[03:36] <habys> it's pretty late here, so I will probably miss any response. Thank you for looking. I have another question that's killing me.. Every time something isn't perfect in my `user-data` file, I get this crash: https://i.imgur.com/UKBUYIR.png
[03:37] <habys> afaict, there is nothing about what caused the crash on the screen and the listed crash file also does not tell what caused the crash.
[03:38] <habys> for example I can put an intentionally bad command in `late-commands:` but I can not grep for it in these logs. Any help there would really really help me, and help me be more self sufficient.
[03:38] <habys> ty! Good night
[07:12] <meena> habys: autoinstall and cloud-init aren't the same thing
[07:15] <meena> I think you wanna ask #ubuntu-server for help here
[11:04] <habys> I thought cloud-init parses `user-data`?
[11:10] <aciba> habys: the autoinstall key is treated as an opaque config, the only validation cloud-init does is checking that a version subkey is present: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ubuntu_autoinstall.py#L135
[11:13] <aciba> habys: the autoinstall config is then handed-over to subiquity
[11:14] <aciba> habys: autoinstall documentation: https://ubuntu.com/server/docs/install/autoinstall
[11:19] <habys> thanks for helping, I'll read this because I am definitely having trouble understanding what the different components are doing
[13:46] <Jack> Hi,
[13:46] <Jack> For file ownership issue, could we need to create a new module to handle it?
[13:46] <Jack> https://bugs.launchpad.net/cloud-init/+bug/1990513/comments/7
[13:46] <Jack> I'd like to hear your advice whether a new module is valuable.
[13:46] -ubottu:#cloud-init- Launchpad bug 1990513 in cloud-init "write_files defer not using ownership for new folders" [High, Triaged]
[13:49] <falcojr> Jack: since we already have the functionality in 'write_files', I think the behavior there could be updated
[13:49] <falcojr> if a directory already exists, don't modify the permissions, but if it doesn't exist, create it with the owner/permissions specified
[13:55] <Jack> Thanks for your suggestion, I'll try to implement it and file a PR for your review
[15:24] <Jack> Hi
[15:24] <Jack> I am trying to Sign the Canonical contributor license agreement.
[15:24] <Jack> What should be filled in 'Please add the Canonical Project Manager or contact'
[15:24] <Jack> It is a required field.
[15:24] <falcojr> you can put James Falcon
[15:25] <Jack> Thanks
[15:25] <Jack> And Launchpad id is username of launchpad, right?
[15:26] <falcojr> yes, that can be left blank if you don't have one
[15:26] <Jack> Got it, thx
[15:37] <minimal> tail g
[15:37] <minimal> oops
[15:37] <minimal> meena: I see you getting a mention: https://www.freebsd.org/status/report-2022-10-2022-12/#_freebsd_as_a_tier_1_cloud_init_platform
[16:04] <meena> minimal: that's not a mention, that's my report
[16:22] <holman> minimal: any reason you can't can't just mock cloudinit.distros.networking.subp.subp" each each test individually?
[16:24] <holman> minimal: the patch in the shared function goes out of scope when the function ends https://docs.python.org/3/library/unittest.mock.html#unittest.mock.patch
[16:24] <holman> I think meena mentioned that in the PR, maybe that got missed
[16:28] <holman> my gut reaction to that set of tests is that there's a lot of repitition
[16:28] <holman> 150 lines in that test class and it's mostly copy/pasta -> some parametrization could make that a lot more succinct
[16:29] <holman> but obviously you didn't write them that way, don't feel like you have to do that
[16:29] <Jack> Hi guys
[16:29] <Jack> Feel free to review this PR if you have time.
[16:29] <Jack> https://github.com/canonical/cloud-init/pull/1980
[16:29] <Jack> Fix https://bugs.launchpad.net/cloud-init/+bug/1990513
[16:29] -ubottu:#cloud-init- Pull 1980 in canonical/cloud-init "Set ownership for new folders" [Open]
[16:29] -ubottu:#cloud-init- Launchpad bug 1990513 in cloud-init "write_files defer not using ownership for new folders" [High, Triaged]
[16:38] <minimal> holman: I did at first try mocking subp in each test and it didn't work - that was before I decided to move the mock to the _mock_init function
[16:42] <holman> minimal: works for me https://dpaste.org/GPoOp
[16:46] <minimal> I haven't had time this week to update the PR with feedback, I'll be doing that later today
[16:50] <holman> +1 sounds good


[21:30] <balloons> welp, my trusty -> xenial test got pretty borked
[21:30] <balloons> lots of hand curation required
[21:30] <dobey> haha, yeah
[21:30] <dobey> i endured that pain yesterday on my laptop
[21:31] <dobey> was not pretty at all
[21:31] <balloons> not sure what exactly caused it (several things), but the worst bits were the upstart / systemd changes
[21:31] <balloons> hand updating packages over one at a time ;-)
[22:00] <flocculant> balloons: sounds like my plan of running development versions always saved me some pain then :p
[22:01] <balloons> flocculant, indeed. Always be current ;-)
[22:01] <flocculant> :)
[22:26] <dobey> balloons: module-init-tools seemed to cause the big issues for me
[22:26] <dobey> and not being able to unlock the screen after it locked during the update
[22:26] <balloons> that was just the tip of the iceberg for me :-)
[22:28] <flocculant> balloons: we got that far testing it over the weekend - didn't bother further
[22:29] <balloons> I saw the bugs / forums posts on it
[22:29] <balloons> it didn't get better for me
[22:29] <flocculant> wouldn't know about forum - don't use it any more - no account there
[22:36] <balloons> OOOOooooOOOOoooOOO
[22:37] <flocculant> lol