[05:50] <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. 
[08:14] <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:16] <meena> I've since tried to rectify that at the source: https://reviews.freebsd.org/D27161
[15:07] <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:58] <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
=== meena7 is now known as meeena
[17:16] <minimal> Vijay: isn't that a yocto-specific issue?
=== meeena is now known as meena
[18:02] <Code_Bleu> Hey meena o/~
[18:04] <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:06] <meena> weird
[18:09] <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:10] <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:12] <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:13] <Code_Bleu> ^ that might not be a deal breaker for me right now, not sure.
[18:15] <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:16] <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:17] <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:19] <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:20] <meena> nope
[18:22] <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 ^
[19:25] <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:40] <Code_Bleu> hrm
[19:41] <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."
[20:10] <meena> I've got code to fix boottime
[20:12] <Code_Bleu> meena: cool!
[20:19] <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:20] <meena> and it'll need unit test fixes 
[20:24] <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:27] <meena> 👍
=== kuraudo1 is now known as kuraudo
[20:40] <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:41] <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:42] <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:44] <Code_Bleu> I believe the UP before was '.....Up ?? seconds' if i 
[20:49] <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:50] <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:51] <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:52] <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:53] <meena> basically, yes
[20:54] <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:55] <meena> if there's a fast way to identify CloudStack, then, yes
[20:57] <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:58] <meena> Code_Bleu: i do see CloudStack in the list
[20:59] <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
[21:00] <Code_Bleu> I was talking about the test_ds_identify.py.  No CloudStack there.
[21:03] <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:04] <Code_Bleu> Yup
[21:06] <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:08] <meena> oh?
[21:11] <Code_Bleu> meena: the only 2 things I'm doing manually outside of my PR changes are these - https://dpaste.com/DMKEVTP9D
[21:14] <meena> Code_Bleu: if cloud-init were a port, you'd put stuff into pkg_…something
[21:15] <meena> Also, i recommend overriding the main config in $etc/cloud/cloud.cfg.d/
[21:21] <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:22] <minimal> nope, to busy with work (Chainguard)
[21:25] <minimal> meena: well still seems to listed as maintainer for some packages but certainly stepped down from some roles due to work pressures
[21:29] <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:33] <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:34] <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:35] <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:45] <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.
[22:16] <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:18] <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:19] <meena> the blkid stuff needs fixing
[22:20] <Code_Bleu> board_name and chassis_asset_tag too?
[22:26] <meena> I think we can ignore those
[22:30] <Code_Bleu> ok
[22:31] <meena> for now
[22:42] <Code_Bleu> meena: pinging the #openbsd channel again for service file stuff.  Hopefully I'll get some good info 😄  
[22:46] <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:47] <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:49] <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:51] <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:52] <holmanb> Code_Bleu: you're saying OpenBSD has no short-lived services?
[22:54] <Code_Bleu> holmanb: check out the dpaste above from what the peeps in OpenBSD are saying.
[22:56] <holmanb> Code_Bleu: did they offer an alternative?
[22:57] <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:58] <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:59] <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 
[23:00] <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:01] <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:02] <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:03] <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:04] <holmanb> Code_Bleu: I mean it might "work" in some senses, but parts would be broken
[23:05] <meena> In FreeBSD we run after networking setup right now, and still work fine
[23:06] <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:07] <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:08] <holmanb> Code_Bleu: and lots of times no remote network configuration is required, so "just work" should work in those scenarios
[23:10] <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:11] <meena> holmanb: we haven't had an activator until Code_Bleu made one lol
[23:12] <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:13] <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:19] <meena> holmanb: yeah it did
[23:19] <holmanb> huh
[23:19] <holmanb> how?
[23:20] <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:21] <meena> the thing is, network Config on BSD is so dead simple, and there's no real difference between Config and bring up
[23:22] <meena> you're literally just putting ifconfig and route directives into rc.conf
[23:26] <holmanb> ahhhhh, freebsd has only a renderer
[23:26] <holmanb> but it works because the renderer acts also as an activator
[23:28] <holmanb> so it's just restarting the networking service after writing the config
[23:29] <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:30] <meena> that would be neat, but not tonight
[23:30] <holmanb> heh, not tonight agreed
[23:31] <holmanb> it complicates things a bit
[23:36]  * holmanb stops looking at renderers and activators in cloudinit/net/ and backs away slowly