| Code_Bleu | minimal: so now my question is...is ds-identify even needed? | 01:34 |
|---|---|---|
| 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. | 01:52 |
| 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:08 |
| 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:11 |
| 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:39 |
| holmanb | Code_Bleu: you misunderstood, minimal said it takes 2.5 seconds without ds-identify to check datasources in python code | 02:46 |
| minimal | holmanb: right. I'll try adding ds-identify to Alpine for the same scenario and see what difference that makes | 03:43 |
| 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:47 |
| minimal | and that's without fixing detect_virtual to call "virt-what" on Alpine which would add some more time | 03:48 |
| holmanb_ | minimal: hmmmmm, that is unexpected | 03:54 |
| 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:56 |
| 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:57 |
| holmanb_ | all good | 03:59 |
| 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:01 |
| 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:02 |
| minimal | scanned through the ds-identify code and see a few other Alpine-related things I'll need to address | 04:20 |
| meena | minimal: you don't need to patch that. you can give ds-identify a config file to read defaults from | 08:07 |
| holmanb | minimal: and actually 0.14 seems a little slower than I'd expect | 10:22 |
| holmanb | But been a while since ive measured | 10:22 |
| meena | holmanb: i just realized: refactoring dmi.py to go into distros would make the fallback to dmi so much easier | 19:41 |
| meena | holmanb: I think I've addressed everything in your review | 20:37 |
| holmanb | +1 | 22:02 |
| holmanb | meena: nice, will try to review Monday | 22:02 |
| holmanb | minimal: Wikipedia suggests that Alpine's shell is actually based on dash (version 0.3.8-5) | 22:09 |
| minimal | holmanb: it is ash from Busybox | 22:48 |
| minimal | https://git.busybox.net/busybox/tree/shell/ash.c | 22:49 |
| minimal | the config info does say it is derived from Debian dash (1997-2005) | 22:51 |
| meena | so, Wikipedia skipped a few decades of info… | 23:16 |
| meena | FreeBSD's sh is also ash, but from NetBSD. | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!