[01:38] <skull-skrimp> When adding your own datasource, the step "Enable datasource by default in ubuntu packaging branches", where is/are these files?
[01:41] <falcojr> we have separate ubuntu/jammy, ubuntu/focal, ubuntu/bionic, and ubuntu/devel branches that have a separate debian/ directory
[01:41] <falcojr> the datasources are listed in debian/cloud-init.templates
[01:42] <falcojr> those need to come as separate PRs, so we (the ones employed by Canonical) can help with that
[01:47] <skull-skrimp> Alright, was testing the DEB_BUILD_OPTIONS=nocheck ./packages/bddeb -d produced
[01:47] <skull-skrimp> and noticed that the datasource isnt getting picked up in 20.04*
[01:48] <skull-skrimp> It seems like its related to that, but not 100% sure
[01:52] <skull-skrimp> Referring to these files basically? https://github.com/canonical/cloud-init/blob/ubuntu/jammy-22.3-hotfix/debian/cloud-init.templates
[01:55] <falcojr> yeah, if you're going to test that way, you should probably add the datasource directly to /etc/cloud/cloud.cfg.d/90_dpkg.cfg. Then "cloud-init clean --reboot --logs", and it should act like a fresh install on a clean boot with the datasource detection code present
[01:57] <skull-skrimp> 99% of my testing has been with debian-11, so want to try outside of that
[02:07] <skull-skrimp> Are there other files that need to be updated possibly? I'm not getting the detection of the datasource.
[02:10] <falcojr> hmmm, as long as the datasource_list is set appropriately (and ds-identify knows how to correctly detect it), that should be it
[02:17] <skull-skrimp> Looks like my ds-identify is bailing at case "$DI_MODE" in check
[02:22] <skull-skrimp> looks like it was running in 'enabled' mode by default on ubuntu, think debian is search
[02:23] <falcojr> ahh, interesting
[02:23] <skull-skrimp> yep, that was it, now it sees datasource
[02:27] <skull-skrimp> On ubuntu server it defaults to enabled in /etc/cloud/ds-identify.cfg, and default is `search` in debian, so yea that was also the diff
=== m_ueberall is now known as ueberall
=== janitha73 is now known as janitha7
[17:45] <minimal> skull-skrimp: out of interest, which cloud provider is NWCS DataSource for?
[17:46] <skull-skrimp> One I'm working on hah
[17:46] <skull-skrimp> As in, its new and you dont know about it except for that PR
[17:46] <minimal> ah, that explains why searching online gave no matches
[17:47] <skull-skrimp> Yea, I'm writing a platform and need to integrate guest images with it via cloud-init
[17:48] <skull-skrimp> In due time, hopefully you do know about it :)
[17:50] <skull-skrimp> I'm trying to write a platform that drastically simplifies guest management (dont like libvirt) with some of the cloud benefits (metadata, etc) with some modern functionality (REST, etc)
[17:51] <minimal> skull-skrimp: like firecracker provides? (in addition to its lightweight VM features)
[17:51] <skull-skrimp> Havent used
[17:51] <minimal> it comes with MMDS (metadata) and REST API
[17:51] <minimal> skull-skrimp: any particular distro you're using for client?
[17:52] <skull-skrimp> 22.04 and Debian rn
[17:52] <skull-skrimp> 20.04*
[17:53] <skull-skrimp> https://github.com/firecracker-microvm/firecracker/blob/cd29c64b35f694a5a442a7778b7c1463551bc1e2/FAQ.md#what-is-the-difference-between-firecracker-and-qemu looks like its alternative to qemu. I use qemu pretty exclusively
[17:55] <minimal> yes firecracker is for microvms, basically only virtio devices, MMIO rather than PCI, stripped down BIOS
[17:55] <minimal> qemu has a similar microvm machine
=== bahama- is now known as bahamat
[23:00]  * meena wonders if her tests would run faster if she scooched over a meter and plugged her laptop in…
[23:01] <meena> nope… not magically
[23:02] <falcojr> pytest-xdist is an extension you can install that'll split your tests among your cores
[23:02] <falcojr> install it and try "pytest -n auto" (though I think we have 3 tests that aren't a fan of that atm)
[23:02] <meena> falcojr: or, i could run: pytest --last-failed
[23:02] <falcojr> that too
[23:03] <meena> brain's not been working great lately,,
[23:03] <meena> there's a few tests that are unusually slow on my system and i don't know why
[23:04] <falcojr> yeah, we've had some of those come around now and then. Usually it's a missed mock somewhere
[23:05] <meena> falcojr: wonder if when i fix the 127 tests that fail when running pytest on FreeBSD, it will speed up…
[23:10] <meena> so, here's my failures: https://bpaste.net/show/AY2Q
[23:10] <meena> i pushed my latest changes… need to goto bed now (will probably still be awake for some questions…)
[23:11] <meena> i can't figure out where to hook in the mocking of ifconfig -a
[23:12] <falcojr> depends on how it's imported...sometimes just subp.subp works, otherwise you need the name of the module that it's being called it
[23:19] <meena> see latest patchset for what I'm doing