[00:01] ok, so they're putting the cart before the horse lol [00:46] you could say that I suppose [00:51] the pr description laid out a plan saying that they'll contribute the datasource next, and I know there is some internal pressure to get it to happen so I wasn't too worried about it [00:51] but I guess normally I'd ask to see the whole PR for a working datasource (though that's admittedly a lot more to review than the +76/-1 they have currently) [00:52] my main concern with their current approach is that I think it's possible (though unlikely) for a false positive based on that grep in /proc/mounts [00:59] holmanb: my fault for not reading the PR properly, doh! [01:00] all good :) [01:01] I'm curious how a WSL datasource is going to work [01:02] especially as yesterday I was talking to someone trying to get cloudbase-init working on Windows lol [01:02] minimal: its going to be a little weird [01:02] heh, cloudbase-init [01:03] is it still maintained? [01:03] yeah it's been around for year, yupe had a look at it yesterday and it has recent commits [01:03] huh [01:04] https://github.com/cloudbase/cloudbase-init/commits/master/ [02:23] * holmanb stops writing words about the aix code [02:24] minimal: oh nice, they plan to add freebsd [02:24] https://cloudbase.it/cloudbase-init/ [09:15] i didn't even see https://github.com/canonical/cloud-init/pull/4713#discussion_r1441224689 [09:15] -ubottu:#cloud-init- Pull 4713 in canonical/cloud-init "Support for AIX" [Open] [09:16] I guess i was too focused on all the other weird things in this [15:09] meena: no worries, and thanks for starting reviewing it [15:09] meena: there's a lot of weirdness to chew on [15:10] yeah, i feel like they need someone to sit down and hold their hand thru this process [15:11] same [15:11] That's why i wrote as much as i did in my initial review [15:12] Honestly maybe i should drop the content that i wrote into the docs [15:12] "so you want to cloud-init to a new platform?" [15:16] holmanb: not sure if you looked at the channel logs for the holiday period, I posted some IBM links re cloud-init, seems like the changes in that PR have been used by them for a long time, one doc talking about a REALLY old cloud-init version [15:16] minimal: i tried hard to repress those memories [15:17] so they're not really porting cloud-init to a "new" platform now, they hacked AIX (and other) support into their own "fork" quite some time ago :-( [15:18] minimal: that doesn't explain the syntax errors tho [15:18] (which i also missed) [15:18] minimal: I must have missed the docs you linked [15:19] minimal: but that doesn't surprise me since the new files have a copyright 2015 [15:30] holmanb: need to go shopping & cooking now. Gimme a shout if you merge my PR so i can update the OpenBSD and FreeBSD ports. [15:36] meena: will try to re-review this morning [15:36] and will ping when done [15:38] meena: I had one question about print_info() in the review, I don't see changes or response on that so guessing that got missed? [15:38] https://github.com/canonical/cloud-init/pull/4677/files#r1441070610 [15:38] -ubottu:#cloud-init- Pull 4677 in canonical/cloud-init "fix(runpath): On *BSD, create /run is not ephemeral" [Open] [15:38] holmanb: https://www.ibm.com/docs/zh-tw/powervc/2.0.1?topic=aix-custom-powervc-cloud-init-modules and https://www.ibm.com/docs/zh-tw/powervc/2.0.1?topic=init-installing-configuring-cloud-aix [15:50] thanks minimal [15:51] last updated 2023 and the second instruction says "make sure python 2.7 is installed" [15:51] oof [17:18] holmanb: oh, you had answered that yourself. [17:19] no, I wasn't answering my own question - just adding context about which ones I think should stay [17:19] I still think we should drop the DI_LOG and ensure_sane_path calls [17:19] unless there is some reason that I haven't realized [17:19] I need to go over that code again. sh is just the worst [17:20] like, imagine having data structures, instead of global variables? [17:20] meena: agreed - could you rewrite ds-identify in rust while you're fixing that? thanks! [17:21] please don't rewrite ds-identify any more until I finish rewriting it! ;-) [17:22] I guess we can all take turns rewriting ds-identify [17:47] I think Odd_Bloke started on actually [17:50] there's https://github.com/OddBloke/distro-info-rs [17:54] ah, here it is, https://github.com/OddBloke/rs-identify [17:57] oh, and obviously I already contributed FreeBSD support, lol [18:01] oh dear, I thought you were joking about Rust... [18:05] I just had another discussion in #bsdports with people complaining about having to compile rust so they can compile python-cryptography [18:06] when the real problem is that due to the way our dependencies are structured, every time curl updates, rust needs to be recompiled, which, imo, is the real problem [18:07] but i repeat myself [18:08] it's not just dependancies, from memory Rust only supports a few archs as "tier 1"...which is not great for distros support a range of archs [18:10] fun fact: I removed dmidecode as dependency on cloud-init in FreeBSD, so that it could be made platform independent [18:11] minimal: I think FreeBSD is a Tier 3 platform…… [18:12] anyway, i don't think anyone is in a hurry to reimplement ds-identify [18:12] it'd be too much work for too little gain [18:13] meena: yupe, unfortunately as my Alpine-related changes to ds-identify use "virt-what" to detect which VM is used that added "dmidecode" back as an Alpine package dep :-( [18:13] virt-what has dmidecode dep [18:13] boooo [18:14] time to either fix dmidecode or virt-what [18:15] oh, cuz you don't have systemd to tell you what virtualization you're on [18:15] virt-what is using dmidecode, don't have time to try and create a virt-what PR to try and use /sys instead [18:15] meena: yupe, precisely [18:15] and I've so far not found a suitable alternative to virt-what [18:17] meanwhile I'm fighting with growpart testcases as I added a new subp call to growpart and need to figure out mocks for those testcases :-( [18:19] https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L455 that sysctl is so handy [18:23] yeah. I'll use virt-what for now but keep an eye out for any suitable alternative in the future [18:24] its only 48kB of shell + 172kB for dmidecode so not a large extra dep [18:36] for this, https://github.com/systemd/systemd/blob/main/src/basic/virt.c#L249 [18:42] that's 1064 lines of non-standalone code, whereas virt-what is shellscript where I could just replace dmidecode calls with reading files in /sys/..............or write my own virt-what alternative in shell also [19:24] yeah I think that there have been a few ds-identify rust attempts in the past [19:25] and I was only joking, not in a hurry to replace it [19:26] meena: FreeBSD & NetBSD are Tier 2 for x86_64 [19:28] same for musl on x86_64 and aarch64 [19:31] the Rust "issue" is more about other archs like armv7, ppc64le and riscv64 (and perhaps even more obscure archs that some distros support) [19:33] given the linux kernel's ongoing adoption, I'm hopefully that will increase pressure for adding tier 1 support to other platforms over time [19:34] also, perhaps wrongly, I get the impression that the whole Rust dev infra is not really distro-friendly, i.e. "oh yeah that code doesn't work because you're using version A.B.C of dep RANDOM-DEP whereas you need to use the git master/main of RANDOM-DEP from 10 minutes ago" [19:35] true - that's always been a problem with OS development though, stability requires maturity and a slower pace of change [19:35] and again, perhaps wrongly, I get the impression that some (much?) Rust stuff just doesn't do releases at all [19:36] there's a reason cloud-init doesn't use the latest jsonschema and tries hard to limit dependencies [19:37] wasn't there a "so when will cloud-init be rewritten in Rust?" issue raised a month or 2 ago? lol [19:37] not sure what you mean by that, crates _are_ releases aren't they? [19:38] whoohooo it's 19:38 and kiddo is asleep and it's before 22:30, which i think is the earliest she's been asleep at for the past two weeks [19:38] So much free time now [19:39] minimal: yeah, those kind of issues are pretty narrow-sighted and also too common from rust fanatics - I left the issue open so that if we get any more I can close them as duplicates [19:39] meena: think we can land the /run one today? [19:40] holmanb: I've never touched Rust myself so I'm probably getting the wrong impression of some stuff but from watching comments in the likes of the alpine devel channel, especially when a new Rust version comes out and it has to be bootstrapped etc [19:41] how many thousands lines of code is cloud-init? [19:42] and how many person-years of engineering is it? [19:43] excluding tests, the python code in cloudinit is around 67k LOC [19:44] including tests somewhere around 150k [19:44] if we set out today to rewrite it bit by bit, with all that we know, about clouds and distros, not so much about python quirks, how many years of engineering would it take to replicate that (while picking up on rust quirks?) [19:44] not stripping whitespace: `find cloudinit -name '*.py' | xargs wc -l` [19:45] meena: perhaps look at what was the CoreOS c-i alternative in GoLang (is "ignition" the same code or another rewrite?) [19:46] ignition is CoreOS-only last time I checked [19:46] and runs from initramfs [19:46] yeah no clue on the engineering time, and frankly not interested in a feature-for-featurer rewrite in any language [19:47] improving performance by augmenting certain parts of cloud-init in a different language might be feasible [19:49] I've not seen any c-i alternative that comes close to c-i in terms of matching its functionality, they usually just implement a few DSes [19:51] and only a few modules [21:03] holmanb: here's what's happening without the DI_LOG=stderr [21:03] tools/ds-identify: 185: 3: Bad file descriptor [21:03] tools/ds-identify: 185: 3: Bad file descriptor [21:47] holmanb: i removed `set_run_path`, because that, as it turns out, is not necessary [22:40] how are you running it? [22:46] meena: see my latest comment [22:53] holmanb: set_run_path needs to come after read_uname_info [22:54] otherwise, i might have to do this: [22:54] https://gist.github.com/igalic/1a959dbeb0f81a516e5a29a518419dfd to ensure we stay working on Linux by default… [22:55] Ahhhh, I forgot that [22:56] that explains why the DI_LOG issue [22:56] it does? [22:56] Because DI_LOG is set in set_run_path [22:57] duh, that's why i have to override it [22:57] * meena shouldn't be doing 3 things at once [22:57] You and me both multitasking a bit too much [22:58] * holmanb is reviewing like 3 PRs at the same time [22:58] I'm writing a project plan, rewatching Life on our Planet for the third time, and trying to make sense of 2000 lines of sh [23:02] I might have an idea for this [23:04] i could also just bomb out in set_run_path if DI_UNAME_KERNEL_NAME isn't set [23:07] Need to drive across town jn a snowstorm first, but i think this is best fixed in the logger function [23:07] Check id DI_LOG is set to "" and set to stderr if not [23:18] holmanb: okay, done. [23:27] Made it [23:28] snack then ill review