[01:34] <Code_Bleu> minimal: so now my question is...is ds-identify even needed?
[01:52] <holmanb> Code_Bleu: it reduces boot time so why wouldn't you use it, even if cloud-init can do mostly the right thing without it?
[01:52] <holmanb> Code_Bleu: Also what we call "cloud-init" is harder to document and and debug and reason about in the general case if each distro / platform chooses chooses a different implementation of the final product.
[02:08] <holmanb> Code_Bleu: it's better to try to stick to a common design pattern unless there is a good reason to deviate - it makes the internal assumptions of the code base simpler too
[02:11] <holmanb> nothing is stopping end users from modifying their images to use it or not, but for the end user that doesn't want to build their own image, I think it is probably a better default than not using it
[02:39] <Code_Bleu> holmanb: does it reduce boot time?  minimal just stated with all of that it still taks 2.5 seconds.  Maybe I'm still missing something.
[02:46] <holmanb> Code_Bleu: you misunderstood, minimal said it takes 2.5 seconds without ds-identify to check datasources in python code
[03:43] <minimal> holmanb: right. I'll try adding ds-identify to Alpine for the same scenario and see what difference that makes
[03:47] <minimal> quickly, just running ds-identify manually on the CLI and looking at the "[up ..." lines at the start and end of /var/run/cloud-init/ds-identify.log appears to show it taking 14 seconds...
[03:48] <minimal> and that's without fixing detect_virtual to call "virt-what" on Alpine which would add some more time
[03:54] <holmanb_> minimal: hmmmmm, that is unexpected
[03:56] <holmanb_> minimal: could you file a bug with the log?
[03:56] <holmanb_> it's really fast on systemd systems, haven't tested elsewhere
[03:57] <minimal> ah, it's 0.14 seconds......doh!
[03:57] <holmanb_> heh, okay much better
[03:57] <holmanb_> no need to file a bug obviously
[03:57] <minimal> misrad the lines, only realised when it ran it via "time"
[03:59] <holmanb_> all good
[04:01] <minimal> the only issue for me is I'd need to patch ds-identify to tweak the DI_DSLIST_DEFAULT value for some images I'm created
[04:01] <minimal> i.e. if I'm not building images for VMware then I don't install py3-netifaces as only VMware needs it
[04:02] <minimal> but then ds-identify has VMware in its DS list to check which would likely error if no py3-netifaces installed
[04:02] <minimal> likewise for Azure and py3-passlib
[04:20] <minimal> scanned through the ds-identify code and see a few other Alpine-related things I'll need to address
[08:07] <meena> minimal: you don't need to patch that. you can give ds-identify a config file to read defaults from
[10:22] <holmanb> minimal: and actually 0.14 seems a little slower than I'd expect 
[10:22] <holmanb> But been a while since ive measured 
[19:41] <meena> holmanb: i just realized: refactoring dmi.py to go into distros would make the fallback to dmi so much easier
[20:37] <meena> holmanb: I think I've addressed everything in your review
[22:02] <holmanb> +1
[22:02] <holmanb> meena: nice, will try to review Monday 
[22:09] <holmanb> minimal: Wikipedia suggests that Alpine's shell is actually based on dash (version 0.3.8-5)
[22:48] <minimal> holmanb: it is ash from Busybox
[22:49] <minimal> https://git.busybox.net/busybox/tree/shell/ash.c
[22:51] <minimal> the config info does say it is derived from Debian dash (1997-2005)
[23:16] <meena> so, Wikipedia skipped a few decades of info…
[23:19] <meena> FreeBSD's sh is also ash, but from NetBSD.