| === janitha72 is now known as janitha7 | ||
| === janitha73 is now known as janitha7 | ||
| meena | aciba: thanks for the review | 12:29 |
|---|---|---|
| aciba | meena: it's a pleasure | 12:36 |
| * meena wonders why holman wants her to remove that # vi: line… | 12:36 | |
| lioyerar | hello everyone, I have a question on module frequency once-per-instance, how cloud-init knows a module with that frequency is already launched? where the information is stored. Thanks | 14:11 |
| lioyerar | Ok, i find a usefull link | 14:38 |
| lioyerar | https://cloudinit.readthedocs.io/en/latest/topics/dir_layout.html | 14:38 |
| aciba | lioyerar: https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination | 14:39 |
| meena | Goneri: heya! I'll be writing lots of code… and probably rewriting lots of your code ;) | 15:14 |
| Goneri | @meena go ahead, ping me if you want me to test your changes. | 15:15 |
| meena | Goneri: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266847 soon easier to test | 15:15 |
| ubottu | bugs.freebsd.org bug 266847 in Ports & Packages "[newport] net/cloud-init-devel" [Affects Only Me, New] | 15:15 |
| meena | also, need to do that for NetBSD and OpenBSD, but, baby steps | 15:15 |
| meena | OpenBSD folks were upset that make test doesn't (even almost) pass | 15:16 |
| meena | and both, NetBSD and OpenBSD have their own cloudy thing, which does some very few basics… | 15:16 |
| === janitha73 is now known as janitha7 | ||
| Goneri | I've got my script that I use for bsd-cloud-image.org, they are all public, but yeah an up to date port is important. | 15:17 |
| Goneri | Cloudy thing? | 15:17 |
| meena | Goneri: http://ports.su/sysutils/cloud-agent for OpenBSD, and ec2_init for NetBSD: https://nxr.netbsd.org/xref/src/distrib/utils/embedded/files/ec2_init | 15:20 |
| === janitha72 is now known as janitha7 | ||
| shivaya | hi folks, is there a way to have cloud-init (user-data) create raid 1 root disk? i was going through the docs and was unable to find any info on that | 16:34 |
| meena | shivaya: unless you do it as a bootcmd, and it doesn't destroy the existing root disk | 16:47 |
| shivaya | meena: how do you mean? let's say I have 2 blank disks and I wanted to have cloud-init make them into mdraid and install the OS on it | 16:58 |
| meena | shivaya: that's not what cloud-init does. you usually put an image onto a machine, and cloud-init fits it properly | 17:40 |
| shivaya | meena: so cloud-init is not supposed to be used as a replacement to the old preseed automated install? | 17:58 |
| holman | meena: no need, you don't have to remove that line | 18:04 |
| holman | meena: I don't see the value in having it in every file (we don't switch format per-file), and only some of the files have that line so for consistency I've been dropping it when I see it. | 18:05 |
| meena | holman: aye, I can drop it, no problem | 18:06 |
| meena | holman: it's not like we don't have an auto formatter | 18:06 |
| holman | meena: right | 18:06 |
| * meena goes to get laptop | 18:07 | |
| holman | meena: that's a pattern I've seen in other older codebases, but it seems a bit dated and I've never gotten a straight explanation on it (why not just mention [neo]vi[m] format expected in a dev doc) | 18:08 |
| meena | holman: dropped it, will follow that in the future with other files | 18:12 |
| holman | mmeena: sounds good :) | 18:12 |
| holman | shivaya: "old preseed automated install" sounds like you're talking about subiquity's autoinstall usage of cloud-init | 18:13 |
| shivaya | holman: yes, i was under the impression that cloud-init is THE new autoinstall method | 18:18 |
| shivaya | now i am confused, can't figure out the difference :) | 18:18 |
| holman | shivaya: Subiquity is an OS installer (which happens to use cloud-init). | 18:18 |
| holman | shivaya: cloud-init: inits cloud images | 18:19 |
| shivaya | pardon my ignorance, what is supposed to be used as autoinstall with subiquity? something like kickstart on RHEL or d-i on debian | 18:20 |
| holman | shivaya: I don't follow the question | 18:20 |
| holman | subiquity is the autoinstaller | 18:21 |
| shivaya | ah not the ubiquty :). say i want to have pxe boot ubuntu iso and run automated install. looking around i figured cloud-init was the way to kick off the automated install like that. sounds like i was on the wrong path | 18:22 |
| meena | yeah, no | 18:22 |
| meena | cloud-init is not a replacement for kick-start or d-i or similar | 18:23 |
| meena | once you're done installing stuff, you create a (golden) image, and go from there | 18:24 |
| holman | Ah, just noticed that the autoinstall docs describe their config as "cloud-init config", which is not actually a valid cloud-init config. That's unfortunate :/ | 18:24 |
| meena | this might be less useful for hardware, unless you're provisioning loads of the same hardware | 18:25 |
| shivaya | i thought i read somewhere that ubuntu is dropping the support for preseed unattended install (d-i) in favor of cloud-init autoinstall | 18:25 |
| shivaya | so what is the preferred way of doing the unattended install these days do you know? | 18:25 |
| shivaya | tbh cloud-init works fine for me for what i need it except the mdraid on root disk | 18:26 |
| shivaya | https://discourse.ubuntu.com/t/server-installer-plans-for-20-04-lts/13631 - this is what i ran across | 18:26 |
| holman | shivaya: yeah, again unfortunate wording by docs of a different project (which causes confusion like this) | 18:30 |
| holman | looks like this maybe -> https://ubuntu.com/server/docs/install/autoinstall | 18:31 |
| holman | just realize that where it says "cloud-init config" it's talking about its own yaml-based config that isn't actually a valid cloud-init config | 18:32 |
| shivaya | thanks for clearing things up, i thought the yaml IS the cloud-init config | 18:32 |
| holman | that's what is says, doesn't it :/ | 18:32 |
| holman | it's not | 18:32 |
| shivaya | gotcha, sorry for the noise on the channel! | 18:33 |
| holman | shivaya: No problem at all, you came to logical conclusions. Sorry I can't help more. | 18:34 |
| shivaya | you helped plenty, thanks again! | 18:34 |
| meena | holman: what needs to happen for my two PRs to be merged? | 18:54 |
| holman | meena: me to look at them, sorry one sec | 18:54 |
| falcojr | holman: and for us to fix integration tests on main... :/ | 18:56 |
| holman | err, that too | 18:56 |
| * meena wonders how hard it would be to fix make check to run on not-Linux | 18:57 | |
| falcojr | holman: I'll get on that | 18:57 |
| holman | falcojr: thanks! let me know if/how I can help | 18:57 |
| holman | (happy to review) | 18:58 |
| meena | who broke then anyway? | 18:58 |
| falcojr | a change to cloud-images | 19:00 |
| meena | 🎶 who are the cookies from the cookie jar 🎶 | 19:01 |
| falcojr | it's an LXD related change that we use in our integration tests | 19:01 |
| === janitha73 is now known as janitha7 | ||
| * meena builds a VM to to … make check… | 19:39 | |
| falcojr | blackboxsw: did we apply the diff here somewhere? https://github.com/canonical/cloud-init/pull/1734 | 19:44 |
| ubottu | Pull 1734 in canonical/cloud-init "testing: focal lxd datasource discovery (SC-1256)" [Merged] | 19:44 |
| falcojr | I could swear I did, but I'm not seeing the change on main | 19:44 |
| falcojr | the diff in the comment, not the actual PR changeset | 19:44 |
| blackboxsw | ahh no falcojr thanks for redirecting me to something useful. | 19:46 |
| blackboxsw | I had said I'd look over the failing integration tests, and my supplemental 'fix' was partway toward that end | 19:46 |
| falcojr | gotcha, I'm currently fixing CI, so was going to steal that | 19:46 |
| blackboxsw | ok thank you | 19:47 |
| blackboxsw | steal away. | 19:47 |
| blackboxsw | I was distracted by openstack multi-nic rendering questions | 19:47 |
| falcojr | "fix your cloud" | 19:47 |
| falcojr | but I have wondered if we should allow a way to override network config in userdata after the fact | 19:48 |
| blackboxsw | hah. historical reference point: James+1 | 19:48 |
| blackboxsw | you mean a network_deferred key? | 19:49 |
| blackboxsw | it would be a cloud-platform generic way to do that if folks really want to override/augment network config beyond what the cloud IMDS or static seed files present to the instance. | 19:50 |
| blackboxsw | and folks wouldn't have to generate custom images and relaunch them, or provide runcmd hacks to regenerate and apply network config after the fact | 19:50 |
| falcojr | yeah, something like that | 19:51 |
| blackboxsw | but there's a lot of potential thrashing... and corner cases. potential of 1. other systemd units/services getting blocked or interrupted when they thing final network config is done, and 2. what does cloud-init do across reboot if network scope is rendered `Event.PER_BOOT` is set does it continue to reapply supplemental user-data config if IMDS base network config changes etc | 19:52 |
| blackboxsw | *when they think final network config is done* | 19:53 |
| blackboxsw | an interesting idea we could spike to see get broader feedback and see possible failure paths. Given the # of requests or attempts for setting network-config in user-data it might be a somewhat applicable use-case for folks who can't control the network metdata surfaced from IMDS and don't want to generate custom images | 19:54 |
| blackboxsw | since you are on CI failures, I'm reviewing PRs. | 19:55 |
| falcojr | https://github.com/canonical/cloud-init/pull/1776 ready for review | 20:49 |
| ubottu | Pull 1776 in canonical/cloud-init "tests: Use LXD metadata to determine NoCloud status" [Open] | 20:49 |
| blackboxsw | falcojr: running it through bionic/focal VM/container now | 20:53 |
| blackboxsw | almost complete on your doc Pr | 20:53 |
| blackboxsw | really nice work on that btw. | 20:53 |
| falcojr | oh whoops...sorry if you were still looking at the LXD one, I took your comment and Brett's +1 as good to go | 21:02 |
| meena | what makes cloud-init decide I need to fetch data from some URL, after reading an instance-id from a locally mounted meta-data? | 21:04 |
| blackboxsw | falcojr: all good, just letting the integration test run out on VM and container, I don't expect a problem, but wanted to see it before our daily jenkins runners see it | 21:04 |
| blackboxsw | meena: generally yes. if instance-id changes from what was cached down in /var/lib/cloud/data/previous-instance-id it'll determine that metadata configuration needs to be reapplied | 21:06 |
| meena | blackboxsw: but I did a cloud-init clean -slr, and I don't think cloud-init ran before | 21:06 |
| blackboxsw | meena: but each cloud platform may surface instance-id changes differently, and each cloud may also force a retry of get_data per boot because the datasource supports EventType.BOOT, network config (Azure, Ec2, OpenStack, Rbxcloud):n | 21:08 |
| meena | blackboxsw: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html so, how misleading is it to create meta-data here? | 21:10 |
| blackboxsw | meena: I didn't follow. | 21:10 |
| meena | blackboxsw: if cloud-init boots, and discovers no-cloud then reads meta-data, and decides to ignore the user-data and fetch it from somewhere else, isn't it… wrong to set meta-data? | 21:12 |
| blackboxsw | still don't follow the train of thought. If you create metadata in /var/lib/cloud/seed/nocloud(-net)?/meta-data and launch any instance on any cloud, NoCloud datasource will get detected even before the cloud-platform (because of /etc/cloud/cloud.cfg.d/*.cfg "datasource_list" key which defines priority order of datasource and metadata discovery. | 21:12 |
| meena | I should check the logs where this goes wrong then | 21:13 |
| blackboxsw | If cloud-init sees nocloud meta-data and user-data files in a seed directory (both are "required": ["user-data", "meta-data"]) to detect nocloud datasource, then cloud-init should be bound to only use NoCloud datasource seed files for the life of cloud-init on that instance/config. It shouldn't also source other user-data sections or IMDS from other clouds. | 21:14 |
| blackboxsw | +1 | 21:14 |
| meena | https://im.eena.me/uploads/553f0e1cba8d0628/cloud-init.tar.gz ← collect-logs | 21:15 |
| blackboxsw | yeah the comment "and fetch it from somewhere else" threw me for a loop as once a datasource is discovered, cloud-init doesn't try to merge any other datasource config sources. Just user-data/meta-data/network-config/vendor-data for NoCloud | 21:16 |
| meena | let's see. | 21:16 |
| blackboxsw | from cloud-init-output logs looks like no ds-identify available because cloud-init is trying all the datasources instead of a subset of viable datasources detected by /usr/lib/cloud-init/ds-identify, assume BSD (and it's you :) ). | 21:18 |
| blackboxsw | python code looks to be trying to detect the right priority order of datasources `2022-10-05 21:02:02,432 - __init__.py[DEBUG]: Looking for data source in: ['NoCloud', 'ConfigDrive', 'Azure', 'OpenStack', 'Ec2'],` | 21:19 |
| blackboxsw | meena: looks like that image doesn't actually have nocloud seed files in /var/lib/cloud/seed/nocloud/user-data/var/lib/cloud/seed/nocloud/user-data or /var/lib/cloud/seed/nocloud-net/user-data. So it says, Nope! " ` SUCCESS: no local data found from DataSourceNoCloud` | 21:21 |
| blackboxsw | note if cloud-init did find non-empty nocloud seed files in /var/lib/cloud/seed/* it would have logged the number of bytes read for those file reads | 21:22 |
| meena | blackboxsw: i have an cd9660 image attached | 21:22 |
| meena | it's not being mounted | 21:22 |
| blackboxsw | meena: is `util.find_devs_with("TYPE=iso9660")` returning anything for you? | 21:30 |
| meena | blackboxsw: i think i have a typo in my image name 😬 | 21:31 |
| meena | i dunno how, but that typo might have also created a 20 GB image… | 21:33 |
| meena | can I alter the "default" user's shell? | 21:35 |
| blackboxsw | I think you may be able to provide this: | 21:40 |
| blackboxsw | #cloud-config | 21:40 |
| blackboxsw | system_info: | 21:40 |
| blackboxsw | default_user: | 21:40 |
| blackboxsw | name: bsduser | 21:40 |
| blackboxsw | shell: <something_else> | 21:40 |
| * meena needs fish as shell, but fish needs installing… | 21:41 | |
| blackboxsw | this is 'off the beaten path' otherwise you could modify the config in /etc/cloud/cloud.cfg on the image to set system_info: default_user: shell: there in the base/system config | 21:41 |
| meena | blackboxsw: everything i do is off the beaten path… | 21:43 |
| * meena grew on Solaris and FreeBSD… in a Linux world. | 21:44 | |
| meena | running gmake check on FreeBSD 14.0-CURRENT now… | 21:45 |
| meena | ========================== 146 failed, 3908 passed, 10 skipped, 240 warnings, 419 errors in 85.07s (0:01:25) ========================== | 21:46 |
| meena | first round | 21:46 |
| meena | now let's see how it fares with bash installed :D | 21:47 |
| holman | meena: I remember now that chkconfig on/off is how the sysv init systems I used to use enabled/disabled services | 21:47 |
| meena | holman: oh, right! I remember that too! | 21:47 |
| holman | I forgot that el6 actually did use sysv | 21:48 |
| meena | ========================== 124 failed, 3930 passed, 10 skipped, 240 warnings, 419 errors in 83.89s (0:01:23) ========================== | 21:48 |
| meena | that's not too bad. | 21:48 |
| holman | Nice :) | 21:50 |
| meena | now with pytest-cov and pytest-mock installed: ================================ 127 failed, 4346 passed, 10 skipped, 243 warnings in 86.72s (0:01:26) ================================ | 22:00 |
| meena | so, just 1 signed byte to fix. | 22:00 |
| meena | E AttributeError: module 'socket' has no attribute 'AF_NETLINK' | 22:01 |
| holman | a _very_ linux attribute right there | 22:01 |
| meena | might be one of those cases where we just add @skip on not-Linux. | 22:02 |
| holman | that's used in Azure's _wait_for_all_nics_ready() | 22:03 |
| meena | aye | 22:04 |
| meena | i think that's enough for tonight tho | 22:04 |
| holman | seeya o/ | 22:05 |
| meena | just to write this down, before i forget: to get tests running on FreeBSD, install: python3, gmake, py39-pytest, py39-responses, py39-pytest-mock, py39-pytest-cov, bash. (the py39- probably varies, and I need to find out how to do better) | 22:08 |
| meena | devel/py-pytest devel/py-pytest-cov devel/py-pytest-mock devel/py-responses | 22:10 |
| meena | o/~ good night now | 22:10 |
| blackboxsw | \o | 22:20 |
| meena | from bed: https://github.com/canonical/cloud-init/pull/1773 green! | 23:11 |
| ubottu | Pull 1773 in canonical/cloud-init "OpenBSD: remove pkg_cmd_environ function" [Open] | 23:11 |
| meena | holman: alpine uses open-rc, which has a service wrapper, but the enable/disable work differently. i talked to minimal about this, and they have a different view on whether to provide such things to begin with | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!