=== IchabodCrane is now known as Kuraokami | ||
Code_Bleu | holmanb: can this getting merged be my b-day present? π ( tomorrow is b-day ) - https://github.com/canonical/cloud-init/pull/4654 | 14:50 |
---|---|---|
-ubottu:#cloud-init- Pull 4654 in canonical/cloud-init "dmi: support OpenBSD native reading" [Open] | 14:50 | |
holmanb | Code_Bleu: heh, maybe | 15:06 |
holmanb | Code_Bleu: happy birthday! | 15:06 |
holmanb | Code_Bleu: no promises on merging, but I'm planning on getting in a review for it today | 15:07 |
* holmanb has a long todo list of PR's to review and wrap up (too many WIP PR's too) | 15:09 | |
meena | holmanb, Code_Bleu: looking at that code I'm thinking it would be nice to build a fallback to dmidecode, but in a new PR. | 15:24 |
Code_Bleu | holmanb: thanks π | 15:45 |
Code_Bleu | holmanb: meena: I was also wondering if there could be some logic in cloud-init somewhere that if ds-identify doesn't work, that it would fallback to using the cloud.cfg. I tested the new stuff ( without the new ds-identify ) and I assumed it would use my cloud.cfg, but it didnt. | 15:47 |
meena | Code_Bleu: no, you have it backwards | 15:47 |
Code_Bleu | holmanb: it is Friday...so I understand the no merge on Fridays π | 15:47 |
meena | if you know that ds-identify won't work, you disable the service and hard-code it into cloud.cfg.d/ | 15:47 |
holmanb | Code_Bleu: I'll break the world on friday with a bad merge and sleep just fine | 15:48 |
holmanb | Code_Bleu: (but then fix it on monday) | 15:48 |
Code_Bleu | meena: ok, with the ds-identify being in my /etc/rc.local ( broken version ), I was just hoping it would see the failure and use the cloud.cfg...but ok. | 15:48 |
holmanb | Code_Bleu: fyi, with only one datasource in datasource_list, ds-identify will use that datasource | 15:49 |
minimal | Code_Bleu: I use cloud-init on Alpine without ds-identify | 15:49 |
holmanb | Code_Bleu: is that what you want? | 15:49 |
meena | holmanb: i don't see what the point is of running ds-identify when you know the datasource_list | 15:49 |
Code_Bleu | holmanb: I had datasource_list: [ ConfigDrive, CloudStack, None ] in my cloud.cfg | 15:50 |
holmanb | meena: sure, if you know what you're running on, why would you try to identify it? | 15:50 |
Code_Bleu | meena: good point i guess | 15:50 |
meena | holmanb: that's very succintly put | 15:50 |
holmanb | on the other hand, however | 15:50 |
holmanb | ..... | 15:51 |
holmanb | what happens if your datasource "changes" in a flaky way? | 15:51 |
meena | I'm going to steal that sentence for my docs | 15:51 |
meena | holmanb: if you're in a hybrid environment and move from OpenStack to AWS | 15:51 |
minimal | exactly, when I build a disk image for a specific cloud or hypervisor I just set the specific datasource | 15:51 |
Code_Bleu | way to keep things minimal π | 15:51 |
minimal | for generic use the default cloud.cfg has a list of all the datasources and it checks each in turn until it finds the appropriate one | 15:52 |
holmanb | which can take a looooong time | 15:52 |
meena | very long time | 15:52 |
meena | minimal: does ds-identify work on alpine? | 15:53 |
minimal | hadn't noticed, then again I don't use generic images often | 15:53 |
minimal | meena: never tried it | 15:53 |
holmanb | disabling cloud-init is really a better choice than generating bad ssh keys via DataSourceNone | 15:53 |
meena | minimal: why not try it now?! | 15:53 |
holmanb | it would be reasonable to add ds-identify as a service before init-local | 15:56 |
minimal | I'd have to check if it has any deps I'd need to add | 15:56 |
minimal | alsof ro some reason I'd thought it was Bash-specific but seems it isn't ~(now) - shellcheck is happy its POSIX | 15:57 |
holmanb | minimal: it uses dash on buntu | 15:57 |
minimal | dash isn't 100% POSIX though, neither is ash on Alpine ;-) | 15:58 |
holmanb | minimal: there are a couple of non-posix things I think (local keyword isn't posix iirc) | 15:58 |
minimal | hmm, must be warnings-ignore for that then as shellcheck normally points that out | 15:58 |
holmanb | but I don't think there are any serious bash-isms besides a couple of things like that | 16:00 |
holmanb | and happy to modify for ash compatibility | 16:00 |
holmanb | lol | 16:00 |
holmanb | $ apt search almquist | 16:00 |
holmanb | Sorting... Done | 16:00 |
holmanb | Full Text Search... Done | 16:00 |
holmanb | dash/lunar,now 0.5.12-2ubuntu1 amd64 [installed] | 16:00 |
minimal | yeah I use "local" myself all the time | 16:00 |
minimal | so it simply needs to be run before cloud-init-local? ~Ok, I'll give ti a try later today | 16:01 |
meena | to be fair, if ds-identify works on FreeBSD, it should work on alpine, too | 16:02 |
holmanb | minimal: yep, before init-local is the right time | 16:04 |
minimal | meena: I'm not saying it won't work, just that I've never tried it & never needed it | 16:04 |
holmanb | minimal: and really, it would be best to be able to disable cloud-init if no datasource is detected | 16:04 |
minimal | and the pre-existing init.d scripts didn't provide one for ds-identify | 16:04 |
meena | rather than running into a 2-15 minute timeout⦠| 16:05 |
minimal | what timeout? | 16:05 |
holmanb | I assume meena is talking about the "timeout" of waiting for attempting to detect each datasource in series for all of the default datasources | 16:07 |
minimal | hmm, don't remember any noticable delay in the past | 16:08 |
minimal | I'll have another look and maybe time it | 16:09 |
meena | I think dch complained about 5~ minutes a few weeks back, because his machine was detected to be on OpenStack | 16:09 |
minimal | wasn't that due to an issue around changes made for BareMetal Openstack use (by OVH) that were later reverted due to unexpected side effects? | 16:10 |
holmanb | meena: ahhh, openstack detection, running on arm? | 16:11 |
meena | yes, most likely on arm64 | 16:12 |
minimal | gotta dash, back on in a while | 16:13 |
holmanb | minimal: that might have been the case too | 16:14 |
holmanb | but openstack doesn't have a good detection mechanism on arm | 16:14 |
holmanb | s/a good/any/g | 16:19 |
Code_Bleu | meena: should I be able to change hostname and password in CloudStack and cloud-init should pick that up without having to do a cloud-init clean, right? | 17:17 |
meena | I don't know, i have to check | 17:18 |
Code_Bleu | I'm seeing in the logs that the set_password and update_hostname are running "successfully", but it's not updating until I do a clean and reboot. | 17:20 |
meena | hostname i can Kind of understand, but password not so much | 17:21 |
Code_Bleu | I'm ok with the reboot, but I didn't think it needed to basically do a clean run of cloud-init to get that. The set_passwords is in the cloud_config_module section, which i thought it would run without a clean. | 17:23 |
Code_Bleu | could it be cached in /run or somewhere and it's a weird thing with OpenBSD again? | 17:23 |
Code_Bleu | I do see those in the /run directory...so maybe it isn't clearing that out like and then the running of cloud-init would then query and get the new values | 17:29 |
Code_Bleu | /run/cloud-init/combined-cloud-config.json:90: "password": "xxxx" | 17:29 |
meena | Code_Bleu: I need to see if I can get this reproduced and debugged | 17:31 |
Code_Bleu | meena: ok, thanks! | 17:31 |
meena | i just have this stupid habit of overengineering thingsβ¦like, I want to create a port before-hand :P | 17:32 |
Code_Bleu | https://dpaste.com/2BT3U6DRK - hostname is in /run file too. Weird thing is ...it has both local- and local_ | 17:32 |
meena | also, CloudStack is not something I can setup easily lol | 17:32 |
meena | so I'll be testing other codepaths, and maybe having to fix those too | 17:32 |
Code_Bleu | meena: actually there is a quick way to setup cloudstack locally..let me find what it's called again. | 17:33 |
meena | to be fair, fixing those things would be good | 17:33 |
meena | let's see how far i'll get | 17:37 |
* meena 's not been feeling great today | 17:40 | |
Code_Bleu | :crossedfingers: | 17:40 |
Code_Bleu | π | 17:40 |
Code_Bleu | sorry to hear that. Hope you feel better soon | 17:40 |
meena | maybe the plague that was β¦ plagueing my family last week has finally caught up with me | 17:40 |
meena | Its not Covid!β’ at least. | 17:40 |
meena | So that's 1 out of a billion other things that's floating around trying to kill us / make a home inside us. | 17:41 |
Code_Bleu | meena: I believe this is what I was talking about with being able to spin up local cloudstack easily. It's been a min. since I've messed with it...but from what I recall it was pretty simple. - https://github.com/apache/cloudstack/blob/4e46f5ad17fa16684b689c061c7cc52ad2e5b7cc/tools/docker/README.md#L9 | 17:42 |
meena | oh no not docker, anything but docker please π | 17:43 |
Code_Bleu | come on...docker is fine π | 17:43 |
Code_Bleu | but then again...I don't know what your main OS you run is...and if it's BSD, then well..maybe docker sucks on that ? | 17:44 |
Code_Bleu | meena: the more I'm looking into things...it's looking more and more like the /run should be cleaned out on reboot and OpenBSD is not doing that. Now the question is...where does cloud-init look to know not to run the "on first boot" stuff? Is that also in /run? | 17:52 |
meena | Code_Bleu: https://github.com/canonical/cloud-init/issues/4180 | 17:54 |
-ubottu:#cloud-init- Issue 4180 in canonical/cloud-init "/run is not ephemeral on *BSD" [Open] | 17:54 | |
meena | it's not highly critical, but it's annoying | 17:54 |
meena | oh, Code_Bleu have you seen https://github.com/canonical/cloud-init/issues/4231 | 17:56 |
-ubottu:#cloud-init- Issue 4231 in canonical/cloud-init "On FreeBSD 13 password is not set after initial reboot with 'set-passwords, always' on CloudStack Datasource" [Open] | 17:56 | |
meena | actually, let's do that hack for now: rm -rf /run ; ln -s /var/run /run | 17:57 |
Code_Bleu | π | 17:58 |
Code_Bleu | meena: that's weird. who is this igalic person that opened up a bug report on this back in June? π | 18:01 |
meena | June? Good grief | 18:02 |
Code_Bleu | You mentioned "not highly critical, but it's annoying"....well I pretty much need it to work so my customers can clicky clicky buttons in our UI to change hostname and reset password π | 18:03 |
meena | yupp, making /run a symlink works. so we can do that before ds-identify and before any other thing runs | 18:03 |
Code_Bleu | π | 18:04 |
meena | as in, it's ephemeral now | 18:04 |
meena | I still need to check the password change still | 18:04 |
Code_Bleu | so, you adding this to existin PR or creating new one? | 18:04 |
Code_Bleu | I'm pretty sure this will fix the password too. I see the password in /run and /run isn't being removed...so | 18:05 |
meena | lemme prototype something | 18:07 |
Code_Bleu | meena: I just tested manually clearing /run and running the "reset password" from my UI that talks to CloudStack...and it worked and changed the pw this time | 18:08 |
meena | O_o | 18:08 |
meena | cool | 18:08 |
meena | we can commit to the hack for now, but I'd still like to be a good Unix citizen and make /run relocatable in our code/installer | 18:09 |
Code_Bleu | so however you plan on getting /run to be /var/run and ephemeral...should fix those issues | 18:09 |
Code_Bleu | meena: is FreeBSD or some BSD your main driver OS you use...or you use something else? | 18:11 |
meena | Code_Bleu: I'm running some Ubuntu derivate on this Laptop (elementary OS), and FreeBSD on my servers. | 18:12 |
meena | In my first job, I was working on Solaris, and even had a Solaris workstation! (tho⦠amd64, not sparc) | 18:13 |
meena | and even tho it was amd64, that's still a long time ago lol | 18:13 |
minimal | at various times in past I had NeXT Cube, Solaris/SPARC "pizza box", HP-UX workstation, and Alpha workstation on my desk ;-) | 18:15 |
minimal | actually I think it was SunOS rather than Solaris | 18:16 |
Code_Bleu | meena: you almost sound as old as me π | 18:17 |
* Code_Bleu is a Gentoo user, but work on all kinds of other Linux distros | 18:18 | |
Code_Bleu | Sorry meena: maybe I was thinking minimal π HP-UX...yuck! | 18:19 |
meena | I have not had a computer in my house before 2000. Tho that doesn't necessarily say anything about my age, just about my economic background. | 18:20 |
minimal | Code_Bleu: a lot of the telco stuff it did in late 90s/early 2000s was either HP-UX or SunOS/Solaris based | 18:21 |
minimal | s/it did/I did/ | 18:21 |
Code_Bleu | meena: also just noticed that in cloud.cfg i have the default user shell: /bin/bash, but for whatever reason the user was created with /bin/ksh. Hrmm | 18:24 |
Code_Bleu | well π© it's /usr/local/bin/bash | 18:25 |
minimal | Code_Bleu: isn't that controlled by the OpenBSD shell defined in cloud.cfg.tmpl? | 18:25 |
Code_Bleu | the default is /bin/ksh, yes...but I just modified my default user and wanted to put bash...so i put /bin/bash and it should be /usr/local/bin/bash | 18:30 |
minimal | cloud.cfg is created from cloud.cfg.tmpl so unless you override the default_user block via a file in /etc/cloud.cfg.d/* then the default will be used | 18:30 |
meena | Code_Bleu: yeah that seems bogus | 18:31 |
minimal | I'll have to modify ds-identifty as its detect_virt (on Linux) only checks via systemd | 18:32 |
meena | here's the patch for now https://gist.github.com/igalic/9b090874cf1cc82009fff6de00cd3470 | 18:34 |
meena | won't be able to commit this until my goblin child is asleep | 18:34 |
Code_Bleu | cool, thanks | 18:35 |
Code_Bleu | meena: openbsd? | 18:37 |
meena | Code_Bleu: i haven't gotten to OpenBSD yet, but also, just put the contents of that precmd function into rc.local | 18:44 |
Code_Bleu | meena: simple enough...just wanted to make sure you didn't have some other way in mind. | 19:14 |
meena | Code_Bleu: update, https://gist.github.com/igalic/ea855d280b4f778a9692a23824c8d5d2 | 19:21 |
meena | now to write some sensible commit message(s) | 19:21 |
Code_Bleu | meena: https://whatthecommit.com/ | 19:35 |
Code_Bleu | just keep refreshing page π | 19:35 |
meena | Code_Bleu: https://github.com/canonical/cloud-init/pull/4677 | 19:41 |
-ubottu:#cloud-init- Pull 4677 in canonical/cloud-init "hack(sysvinit): On *BSD, create /run as symlink" [Open] | 19:41 | |
meena | that's what I generally try to do: https://whatthecommit.com/c8a751333acd8052477112b0dd9a24d4 | 20:26 |
holmanb | meena: nice work on the openbsd PR | 21:01 |
holmanb | meena: just submitted a review | 21:01 |
holmanb | Code_Bleu: ^ | 21:01 |
holmanb | rm -rf /run | 21:08 |
* holmanb blinks | 21:08 | |
meena | holmanb: we live dangerously ;) | 21:15 |
meena | I could issue a warning instead to have the admin do it themselves | 21:16 |
holmanb | heh | 21:18 |
holmanb | if /run is not expected to be ephemeral, what does it mean for any other project that expects files there to exist across boots? | 21:19 |
* holmanb thinks about how we might integrate Path's assumptions into the build system | 21:20 | |
meena | holmanb: /run doesn't exist on BSD | 21:21 |
holmanb | then why do we need to rm -rf it? | 21:22 |
holmanb | would it not suffice to leave the symlink where it is? | 21:22 |
meena | that's in case this is an upgrade, and it already is created, but not a symlink | 21:23 |
holmanb | why would it be anything other than a symlink? | 21:23 |
holmanb | something across upgrade do that? | 21:23 |
meena | ds-identify creates it on / right now | 21:23 |
meena | as normal directory structure. if we preempt that by making /run a symlink, the directory structure it creates is ephemeral | 21:25 |
holmanb | right, but that's only because ds-identify doesn't know that PATH_RUN should point at /var/run | 21:30 |
holmanb | I assume you're not wrong, but this hack and doing this in the build system should be about the same level of work, I think | 21:31 |
meena | if we do it in the build system, we'd have to make ds-identify a template and that would complicate things | 21:33 |
holmanb | speaking of, should openbsd be setting the same file variables as freebsd/dragonfly? | 21:33 |
meena | hmm? | 21:33 |
holmanb | meena: I don't think templetizing ds-identify is necessary | 21:33 |
holmanb | or even modifying it | 21:33 |
holmanb | just set the PATH_RUN environment variable in the init script that runs ds-identify | 21:34 |
holmanb | the build system integration would be to get helpers.Path to do the right thing | 21:36 |
holmanb | actually, build system integration wouldn't be necessary either | 21:37 |
holmanb | ugh, this reminds me why I hate Paths | 21:38 |
meena | env PATH_RUN=/var/run ds-identify | 21:40 |
meena | the problem with that is that we then need to teach admins to do this too during debugging, and that we need to teach the rest of python cloud-init where to find /run | 21:42 |
holmanb | python cloud-init can be set in cloud.cfg | 21:42 |
holmanb | via system_info.paths.run_dir | 21:43 |
holmanb | and wouldn't admins use the dsidentify init script anyways when debugging? | 21:46 |
meena | I⦠dunno? | 21:47 |
meena | depends on what we tell them to do, i guess | 21:47 |
holmanb | I'm hesitant to add a hack when we have what we need already (in a more elegant way), just need to update the default config for bsd and set the env variable | 21:49 |
meena | i agree but still think the environment variable is too fragile | 21:51 |
meena | if we could pull uname parsing before evaluation of the RUN_PATH we could just say if $DI_UNAME_KERNEL = Linux, do current behaviour, else set the default to /var/run | 21:54 |
holmanb | True, that could work | 21:59 |
minimal | FYI simple "generic" test on Alpine with NO ds-identify involved and cloud.cfg containing DS list of: ConfigDrive,LXD,OpenNebula,Azure,AltCloud,OVF,MAAS,GCE,OpenStack,AliYun,Vultr,Ec2,CloudStack,Bigstep,Scaleway,Hetzner,IBMCloud,Oracle,Exoscale,RbxCloud,UpCloud,VMware,NWCS,Akamai,NoCloud,None | 22:10 |
minimal | in init-local stage it took 2.5 *seconds* to check through that list (including searching for various local ISOs/fses) before finding the NoCloud ISO | 22:10 |
minimal | a far way from 2-15 minutes... | 22:11 |
minimal | obviously would be a bit different for a test using Metadata Servers rather than local ISO | 22:13 |
meena | minimal: I would've thought it goes searching in that order | 22:33 |
meena | never mind, when i properly think about it, this makes sense | 22:40 |
minimal | meena: it DOES go searching in the defined DS order yet only takes 2.5 seconds | 23:32 |
minimal | it checks filesystems to mount, it checks /sys/class/dmi/, does ephemeral DHCP (for GCE Local) etc | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!