| holmanb | meena: what do you want exit status for? I get that the rcs interface is awkward but it does standardize command failure a bit, and I'm hesitant to add a second interface that does the same thing unless there's something we can't do with the existing one. | 05:50 |
|---|---|---|
| meena | holmanb: I've had to add error parsing to some commands to know whether a failure was something i need to act upon, or if it was acceptable to ignore | 08:14 |
| meena | I've since tried to rectify that at the source: https://reviews.freebsd.org/D27161 | 08:16 |
| Code_Bleu | holmanb: meena: Is there a reason we have linting disabled in the .pylintrc file, but then we are failing CI/CD jobs because of linting? It would have been nice if this wasn't disabled for things like "unused imports" and I would have caught it in my editor before submitting a PR - https://github.com/canonical/cloud-init/blob/12bb6818a5ef5a7bd896ffffcc28093c9821967d/.pylintrc#L30 | 15:07 |
| Vijay | Hi Everyone, I am new here and was trying to build an custom yocto distro. While I am running bitbake core-image-minimal command I am getting below error: | 15:58 |
| Vijay | | DEBUG: Python function extend_recipe_sysroot finished | 15:58 |
| Vijay | | DEBUG: Executing shell function do_install | 15:58 |
| Vijay | | git describe version (None) differs from cloudinit.version (20.3) | 15:58 |
| Vijay | | Please get the latest upstream tags. | 15:58 |
| Vijay | | As an example, this can be done with the following: | 15:58 |
| Vijay | | $ git remote add upstream https://git.launchpad.net/cloud-init | 15:58 |
| Vijay | | $ git fetch upstream --tags | 15:58 |
| === meena7 is now known as meeena | ||
| minimal | Vijay: isn't that a yocto-specific issue? | 17:16 |
| === meeena is now known as meena | ||
| Code_Bleu | Hey meena o/~ | 18:02 |
| meena | Code_Bleu: yes, I'm back. (I've managed to pay for my server that runs my IRC) | 18:04 |
| Code_Bleu | Are you sure we need the set_password() in distros/openbsd.py ? I just went through a complete clean up of everything, including resetting my pw and ssh keypair within CloudStack and rebooted my instance, and it actually set the password and the ssh key in authorized_keys. I was able to ssh with the key, and i removed the key and the password worked too! | 18:04 |
| meena | weird | 18:06 |
| meena | Code_Bleu: it falls back to https://github.com/canonical/cloud-init/blob/main/cloudinit/distros/__init__.py#L897 and OpenBSD doesn't have chpasswd | 18:09 |
| Code_Bleu | meena: yeh, i was looking at this - https://github.com/canonical/cloud-init/commit/993f3e3e76e56266a83776a8f54dbb3ba59cfce7 | 18:10 |
| -ubottu:#cloud-init- Commit 993f3e3 in canonical/cloud-init "set_passwords: avoid chpasswd on BSD (#268)" | 18:10 | |
| Code_Bleu | I'm soo close to getting a working cloud-init openbsd image...woo whoo. | 18:12 |
| Code_Bleu | next issue in log to look into: https://dpaste.com/DZX7E8QXW | 18:12 |
| Code_Bleu | ^ that might not be a deal breaker for me right now, not sure. | 18:13 |
| Code_Bleu | The next real thing I'd like to test to see if it will work, is 1. resize disk? 2. figure out better way to use services instead of commands in /etc/rc.local. *Note: I'll prob roll with /etc/rc.local unless you or someone else can help figure out the services better. | 18:15 |
| meena | Code_Bleu: a lot has changed since that commit… | 18:16 |
| meena | and for FreeBSD we have a working implementation but not for OpenBSD | 18:16 |
| meena | oh no that boottime thing is my code :( | 18:16 |
| meena | yeah, OpenBSD doesn't have libc.sysctlbyname() | 18:17 |
| Code_Bleu | meena: I get it needs to prob be better, but I'm kinda operating at a "if it works for me, i can get this image out there and help my customers be able to use OpenBSD image". 😄 | 18:17 |
| meena | but at least it has kern.boottime lol | 18:17 |
| Code_Bleu | I'd love to spend forever optimizing this with you 😄 , but I've got to get a working OpenBSD image so I can move on to other things...and still come back and help clean things up | 18:19 |
| Code_Bleu | meena: did you see my question above about the .pylintrc? | 18:19 |
| meena | nope | 18:20 |
| Code_Bleu | holmanb: meena: Is there a reason we have linting disabled in the .pylintrc file, but then we are failing CI/CD jobs because of linting? It would have been nice if this wasn't disabled for things like "unused imports" and I would have caught it in my editor before submitting a PR - https://github.com/canonical/cloud-init/blob/12bb6818a5ef5a7bd896ffffcc28093c9821967d/.pylintrc#L30 | 18:22 |
| Code_Bleu | that was it ^ | 18:22 |
| meena | hrm, is it time to revert this: https://github.com/canonical/cloud-init/commit/7aa26486394f98dbc2bb3b61f9d49671e6d32af1 ? | 19:25 |
| -ubottu:#cloud-init- Commit 7aa2648 in canonical/cloud-init "Use wget to fetch CloudStack passwords." | 19:25 | |
| Code_Bleu | hrm | 19:40 |
| Code_Bleu | if you haven't searched it yourself, here is the link to the commit in Cloudstack that commit talks about - https://github.com/apache/cloudstack/commit/a72f14ea9cb832faaac946b3cf9f56856b50142a | 19:41 |
| -ubottu:#cloud-init- Commit a72f14e in apache/cloudstack "Ensure the response is a proper http response." | 19:41 | |
| meena | I've got code to fix boottime | 20:10 |
| Code_Bleu | meena: cool! | 20:12 |
| meena | Code_Bleu: https://github.com/canonical/cloud-init/pull/4667 | 20:19 |
| -ubottu:#cloud-init- Pull 4667 in canonical/cloud-init "fix(util): Fix boottime to work on OpenBSD" [Open] | 20:19 | |
| meena | not tested on OpenBSD yet | 20:19 |
| meena | and it'll need unit test fixes | 20:20 |
| Code_Bleu | meena: I had put my PR in Draft mode, but am taking back out of Draft mode, as all linting is working and I think everything else should be good. | 20:24 |
| meena | 👍 | 20:27 |
| === kuraudo1 is now known as kuraudo | ||
| Code_Bleu | meena: I tested with your updated boottime code and it seems to work. I don't see that error anymore. - http://sprunge.us/iidhbs | 20:40 |
| meena | Code_Bleu: but do you get the correct uptime in the logs? ;) | 20:41 |
| Code_Bleu | I don't understand the cdrom errors at top though. Why is/should it be checking cdrom? | 20:41 |
| Code_Bleu | this? Cloud-init v. 23.4 finished at Tue, 05 Dec 2023 20:37:32 +0000. Datasource DataSourceCloudStack. Up 32.560216426849365 seconds | 20:42 |
| Code_Bleu | I believe the UP before was '.....Up ?? seconds' if i | 20:44 |
| meena | and 32 seconds sounds realistic, though a bit slow, but we're all working on speeding it up | 20:49 |
| meena | so it looks like we got all the pieces? | 20:49 |
| meena | ds-identify / DMI will need unittest (fixes) | 20:50 |
| Code_Bleu | I think so. Other than the cdrom stuff I don't understand. | 20:50 |
| Code_Bleu | Should disk resize work with BSD? | 20:50 |
| meena | it only works with FreeBSD | 20:50 |
| meena | and potentially NetBSD, when using ZFS | 20:51 |
| meena | FreeBSD is the only BSD that has a UFS that can be resized online. | 20:51 |
| Code_Bleu | OK, then if it's possible...then I'd like to see about getting this working for OpenBSD next then ;) | 20:51 |
| Code_Bleu | oh... | 20:51 |
| meena | so, that'd mean you'd need an initrd that boots before your OS and handles that | 20:51 |
| meena | There are standard procedures out there you can read up on, but I'm unfortunately not familar | 20:52 |
| meena | The only other UFS that I've had extensive exposure to was Solaris, they also added online resizing decades ago | 20:52 |
| Code_Bleu | initrd for openbsd to do resize of disk before "switch root" to boot? | 20:52 |
| meena | basically, yes | 20:53 |
| Code_Bleu | when I was looking into the ds-identify i did see unit tests needing updated, like you said. I also saw that in the tests, It didn't have CloudStack as an option..so might be good to get that in there eventually, correct? | 20:54 |
| meena | https://unix.stackexchange.com/questions/527349/how-do-i-increase-root-partition#comment976383_527383 | 20:54 |
| meena | if there's a fast way to identify CloudStack, then, yes | 20:55 |
| Code_Bleu | does sysctl hw.product not work? it returns hw.product=CloudStack KVM Hypervisor | 20:57 |
| meena | well, then we just need to add it! | 20:57 |
| meena | Code_Bleu: i do see CloudStack in the list | 20:58 |
| meena | dmi_product_name_matches "CloudStack*" && return $DS_FOUND | 20:59 |
| Code_Bleu | Maybe it was just in the unit tests I didn't see it. I'll look again | 20:59 |
| Code_Bleu | I was talking about the test_ds_identify.py. No CloudStack there. | 21:00 |
| meena | anyway, we need to figure out a hands-free setup for bsd.rd + growfs, and we need the port, then your work is pretty much complete, Code_Bleu | 21:03 |
| Code_Bleu | Yup | 21:04 |
| Code_Bleu | and better service file handling at boot. Until then, my PR only creates the service files, but I didn't have the build-on-openbsd add it to /etc/rc.local ...unless we want to do that for now, and then it can always be cleaned up later? | 21:06 |
| holmanb | minimal: your ifupdown-ng PR just landed | 21:06 |
| meena | oh? | 21:08 |
| Code_Bleu | meena: the only 2 things I'm doing manually outside of my PR changes are these - https://dpaste.com/DMKEVTP9D | 21:11 |
| meena | Code_Bleu: if cloud-init were a port, you'd put stuff into pkg_…something | 21:14 |
| meena | Also, i recommend overriding the main config in $etc/cloud/cloud.cfg.d/ | 21:15 |
| minimal | holmanb: I'd forgotten about that lol (I added it as a patch to Alpine's package back in Jan) | 21:21 |
| meena | minimal: isn't kaniini also an alpine dev? | 21:21 |
| minimal | nope, to busy with work (Chainguard) | 21:22 |
| minimal | meena: well still seems to listed as maintainer for some packages but certainly stepped down from some roles due to work pressures | 21:25 |
| meena | Code_Bleu: "Services installed from packages(7) may be started at boot time in the order specified by the pkg_scripts variable from rc.conf(8); the order will be reversed during shutdown. Services comprising OpenBSD base are started by rc(8)." there we go | 21:29 |
| Code_Bleu | I kinda got the pkg_scripts working and running rcctl order command, but it would only run the first service "cloudinitlocal" and wouldn't do the rest. I kinda thought for that to work it might have been expecting all of the services to be in a "running" state and somehow the next service needs to know it was complete to kick off the next service????? | 21:33 |
| Code_Bleu | meena: ^ | 21:33 |
| meena | good question. maybe a better question for #openbsd :) | 21:34 |
| meena | it'll try to get my unittests fixed, and we can see if we can get a port submitted | 21:34 |
| meena | You can volunteer as maintainer, sine you are more experienced with OpenBSD :P | 21:34 |
| Code_Bleu | 💥 | 21:34 |
| Code_Bleu | yeh right | 21:35 |
| Code_Bleu | I just started messing with BSD a few days ago. I do run pfsense firewall which I believe is FreeBSD, but I mainly stay in the UI for that 😄 | 21:35 |
| Code_Bleu | I'm going to try something. I'm going to remove the REQUIRE in the service itself, because I think that might be looking for the other service to be running ( which it wont be ) and therefore it wont start itself. I'm going to remove it from the service file and just depend on the pkg_scripts= to set the order. | 21:45 |
| Code_Bleu | meena: I decided to run ds-identify again after your recent changes and it appears to detect CloudStack! - https://dpaste.com/FED99P4P3 | 22:16 |
| Code_Bleu | meena: couple questions about that: 1. should we not have any ERRORS from running ds-identify? that is the top of the dpaste link. 2. With this working, should ds-identify be a service as well, or is it called someother way? | 22:18 |
| meena | the blkid stuff needs fixing | 22:19 |
| Code_Bleu | board_name and chassis_asset_tag too? | 22:20 |
| meena | I think we can ignore those | 22:26 |
| Code_Bleu | ok | 22:30 |
| meena | for now | 22:31 |
| Code_Bleu | meena: pinging the #openbsd channel again for service file stuff. Hopefully I'll get some good info 😄 | 22:42 |
| holmanb | > should ds-identify be a service as well, or is it called someother way? | 22:46 |
| holmanb | it must be capable of disabling the other services, cloud-init's services don't call it directly | 22:46 |
| holmanb | @Code_Bleu | 22:46 |
| Code_Bleu | I'm going to try setting the daemon_timeout=5 for each service. Sucks, to have it wait 5 seconds for each service...but that might work. | 22:46 |
| Code_Bleu | holmanb: what calls ds-identify? | 22:47 |
| holmanb | Code_Bleu: on systemd, ds-identify gets invoked by a systemd-generator (before all other services) | 22:47 |
| holmanb | https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init-generator.tmpl | 22:47 |
| Code_Bleu | meena: if you're still up, you can see the response in #openbsd. If not, i tried to capture it here - https://dpaste.com/BLBPF37KA | 22:49 |
| holmanb | Code_Bleu: that's a bunch of bash that basically does -> "if ds-identify discovers a cloud/datasource, then enable the cloud-init services, otherwise disable cloud-init services" | 22:49 |
| Code_Bleu | holmanb: ok, thanks. I think the issue with OpenBSD is the services there are not typical to just execute and be done. Seems they expect to stay running. ( which is what I would have assumed for services as well ). So, this is my current issue with "needing" to create services or just have the cloud-init commands ran from /etc/rc.local ( which seems to work in my testing ) | 22:51 |
| holmanb | Code_Bleu: you're saying OpenBSD has no short-lived services? | 22:52 |
| Code_Bleu | holmanb: check out the dpaste above from what the peeps in OpenBSD are saying. | 22:54 |
| holmanb | Code_Bleu: did they offer an alternative? | 22:56 |
| Code_Bleu | meena: holmanb: I don't know. The more and more I think about it with OpenBSD, I'm thinking the /etc/rc.local is the way to go 😄 Again, unless I'm missing something that would actually need it to be a service for some reason? | 22:57 |
| meena | I think that's what Goneri does, too | 22:57 |
| holmanb | Code_Bleu: no clue what "service" and "rc.local" mean, /shrug | 22:57 |
| holmanb | Code_Bleu: sorry | 22:57 |
| holmanb | Code_Bleu: but from rc.8 "Normally, rc.local contains commands and daemons that are not part of the stock installation." | 22:58 |
| Code_Bleu | holmanb: basically in /etc/rc.local it is running the cloud-init commands and a wait. That's it. | 22:58 |
| holmanb | Code_Bleu: so sounds like you're on the right track | 22:59 |
| holmanb | Code_Bleu: but also "rc.local is executed towards the end of rc" | 22:59 |
| Code_Bleu | holmanb: that is how I have it working currently...but thought I might have needed to have a bether "service" approach...but it's not looking promising | 22:59 |
| holmanb | which makes it sound like maybe not all of the services should go there, since cloud-init needs to to be running before network is up to operate correctly | 23:00 |
| meena | yeah, in FreeBSD, we have a bunch of things that are just tasks, like clean_var, and we can still depend on them / their completion | 23:00 |
| holmanb | Code_Bleu: most projects should never need to hijack the init system and hold it hostage until network configuration can be remotely gathered, but that's precisely what cloud-init does, so that it can have a network configuration ready on first boot | 23:01 |
| meena | but FreeBSD's rc has diverted from NetBSD's massively. don't know if NetBSD supports that, or where OpenBSD's rc is from | 23:01 |
| Code_Bleu | I believe OpenBSD is a fork of NetBSD | 23:02 |
| meena | aren't we all | 23:02 |
| meena | holmanb: i might have to rethink some ordering in FreeBSD… | 23:02 |
| holmanb | my lineage is traced from multics thank you :P | 23:03 |
| Code_Bleu | holmanb: but, the way i have it in the /etc/rc.local seems to work for me though. So, i'm not really understanding the "hijack" part. | 23:03 |
| holmanb | Code_Bleu: I mean it might "work" in some senses, but parts would be broken | 23:04 |
| meena | In FreeBSD we run after networking setup right now, and still work fine | 23:05 |
| holmanb | Code_Bleu: "hijack" as in, cloud-init sets up an ephemeral network to grab a remote config with the intention of dropping configurations in place before services start | 23:06 |
| holmanb | Code_Bleu: the local stage should apply the networking configuration to the system before boot. However, if your OS's networking service does something reasonable with a default configuration (i.e bring up network with dhcp), and network configuration is not needed, then yeah it will "work" | 23:07 |
| holmanb | Code_Bleu: and lots of times no remote network configuration is required, so "just work" should work in those scenarios | 23:08 |
| holmanb | meena: does network v1/v2 work for freebsd? | 23:10 |
| holmanb | meena: if so, I think the network activator should be what makes that possible | 23:10 |
| holmanb | meena: but that would require a networking restart iirc | 23:10 |
| meena | holmanb: we haven't had an activator until Code_Bleu made one lol | 23:11 |
| Code_Bleu | holmanb: https://github.com/canonical/cloud-init/pull/4660/files | 23:12 |
| meena | but, iirc, Config Drive uses one of those, and that worked out fine | 23:12 |
| -ubottu:#cloud-init- Pull 4660 in canonical/cloud-init "fix(openbsd): services & build tool" [Open] | 23:12 | |
| meena | Code_Bleu: i know i approved this already, but i feel like this should be split into multiple commits | 23:12 |
| Code_Bleu | meena: I was just pointing out the activator change to holmanb :) | 23:13 |
| holmanb | did network config work at all on freebsd? I assume not | 23:13 |
| meena | holmanb: yeah it did | 23:19 |
| holmanb | huh | 23:19 |
| holmanb | how? | 23:19 |
| meena | on FreeBSD we explicitly have no Activator. check the code. i think you might've written it | 23:20 |
| holmanb | lol, maybe I did XD | 23:20 |
| meena | the thing is, network Config on BSD is so dead simple, and there's no real difference between Config and bring up | 23:21 |
| meena | you're literally just putting ifconfig and route directives into rc.conf | 23:22 |
| holmanb | ahhhhh, freebsd has only a renderer | 23:26 |
| holmanb | but it works because the renderer acts also as an activator | 23:26 |
| holmanb | so it's just restarting the networking service after writing the config | 23:28 |
| holmanb | which is no big deal sometimes I guess, but cloud-init is also capable of writing the config prior to ever starting networking -> so no network restart required | 23:29 |
| meena | that would be neat, but not tonight | 23:30 |
| holmanb | heh, not tonight agreed | 23:30 |
| holmanb | it complicates things a bit | 23:31 |
| * holmanb stops looking at renderers and activators in cloudinit/net/ and backs away slowly | 23:36 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!