| minimal | meena: I'm sure I've done that in the past | 00:24 |
|---|---|---|
| minimal | what does the cloud-init.log show? generally when using NoCloud I see in the log it checking for that file | 00:26 |
| minimal | as well as a version in nocloud-net | 00:26 |
| meena | minimal: it's checking for that file, reading that file, and then, apparently, ignoring that file. | 00:36 |
| minimal | meena: you're right, I'm seeing the same | 01:32 |
| * meena blames blackbox | 08:45 | |
| * dch waves to meena | 12:19 | |
| dch | also if you have OpenBSD questions just @ me, I have some of them over there (gestures vaguely downwards) | 12:22 |
| meena | dch: I need someone to create a port for cloud-init and cloud-init-devel | 13:02 |
| dch | on OpenBSD ? | 13:02 |
| dch | we should probably ask an OpenBSD person on masto. | 13:02 |
| meena | dch: yeah | 13:02 |
| dch | meena: its not going to be me, I can't be bothered re-learning cvs | 13:03 |
| dch | https://github.com/exoscale/openbsd-cloud-init ;-) add another CI rewrite to the list | 13:04 |
| meena | dch: i reckon you've seen https://reviews.freebsd.org/D37479 | 13:06 |
| dch | yup | 13:06 |
| dch | and you know of cperciva's ones, and jmg's one also ? | 13:07 |
| dch | with illustrious names like these, I feel compelled to write my own one in the most obscure language I can think of | 13:07 |
| dch | probably some ocaml derivative would do | 13:07 |
| dch | meena: btw do you know how to get c-i to produce an actual log file on FreeBSD? | 13:08 |
| dch | I see it in console log, but not in its nice happy own log | 13:08 |
| meena | dch: jrm and I fixed that in net/cloud-init-devel | 13:09 |
| dch | oh cool | 13:09 |
| dch | so I just use the -devel port | 13:09 |
| dch | glad I asked :-) | 13:09 |
| meena | https://codeberg.org/FreeBSD/freebsd-ports/commit/63c72b063ac9cb4d2ad599448c528fb4d0afa363 | 13:11 |
| -ubottu:#cloud-init- Commit 63c72b0 in FreeBSD/freebsd-ports "net/cloud-init-devel: Update and fix config file installation" | 13:11 | |
| meena | I think we'll have to port that back to net/cloud-init as well | 13:12 |
| meena | cuz it's the right way to do it | 13:12 |
| dch | IMO it would be great to use proper /var/run/cloudinit and /var/db/cloudinit dirs instead of those linuxisms that were done in the original port | 13:13 |
| dch | meena: reading that its just the logging.cfg that was never copied across? or does it use upstreamed c-i chnages? | 13:14 |
| dch | i.e. if i drop 05_logging.cfg onto net/cloudinit does that work? | 13:15 |
| dch | the .sample files look identical | 13:17 |
| meena | just remove the .sample extension | 13:18 |
| dch | I just tested on the non-devel port, it also works | 13:21 |
| dch | so I can slam that file into the builds and finally have both logs and debugging output | 13:21 |
| dch | thank-you again meena ! | 13:21 |
| meena | we'll get half of IPv6 soon in net/cloud-init-devel | 13:21 |
| dch | feel free to @ me whenever you need it, I can test it on OCI & Equinix as required | 13:26 |
| meena | thank you, dch! | 13:37 |
| blackboxsw | — meena blames blackbox (I didn't get the joy of IRC notification for just 'blackbox') I'll have to update my client config :) | 18:59 |
| meena | blackboxsw: didn't mean to mention you directly :P | 18:59 |
| meena | but, yeah, no idea how to use /var/lib/cloud/seed/ directly | 19:00 |
| blackboxsw | ahh then, msg properly received :). | 19:01 |
| blackboxsw | Meena/falcojr I'm leaning toward removing the documented option for NoCloud datasource sourcing %dmi.<some_kenv_var>% when contructing seedurls in this PR https://github.com/canonical/cloud-init/pull/1879/files#r1038438401. I had itematized in docs (and variabe alias support) DMI generic characteristics (top-level keys) as well as the distro-specific aliases for /sys/class/dmi/id/<filename> vs BSD's kenv variable names. | 19:02 |
| -ubottu:#cloud-init- Pull 1879 in canonical/cloud-init "nocloud: add support for dmi variable expansion for seedfrom URL" [Open] | 19:02 | |
| blackboxsw | Any concern with either of you if I drop the Linux specific and BSD-specific BSD template variable aliases and just force people who want such values to use the distro-agnostic DMI string name? | 19:03 |
| falcojr | blackboxsw: No concern from me. That's my preference anyhow | 19:04 |
| meena | blackboxsw: same | 19:04 |
| blackboxsw | It's probably trying to be 'too flexible' for cloud-init to allow distro-specific DMI keys anyway | 19:04 |
| blackboxsw | ok. | 19:04 |
| blackboxsw | > but, yeah, no idea how to use /var/lib/cloud/seed/ directly...... Basically just need a /var/lib/cloud/seed/nocloud-net/ directory with minimally 2 yaml files user-data and meta-data (both could be empty). user-data file should begin with #cloud-config header, but meta-data can be simple key: value | 19:06 |
| blackboxsw | ok. per DMI variable expansion in nocloud seedurls (and our simple helper function) I'll drop the distro-specific kenv & /sys/class/dmi/id/<file_name> support | 19:07 |
| blackboxsw | thx | 19:07 |
| blackboxsw | I need to check your failure case there meena. The seed directory will only ignore those files if minimally both user-data and meta-data are not present Both are required to provide enough info for nocloud to claim the seed directory is valid. I presume in your case only user-data was present in the directory | 19:09 |
| blackboxsw | .... and that cloud-init didn't do a good job of reporting a warning about the absence of meta-data or something | 19:10 |
| meena | blackboxsw: wait, i need meta-data too? | 19:10 |
| meena | lemme check | 19:10 |
| blackboxsw | "Both files are required to be present for it to be considered a valid seed ISO." per https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html | 19:12 |
| blackboxsw | the optional files that could be provided are network-config and vendor-data | 19:12 |
| blackboxsw | That statement should probably be more noticeable on the docs page | 19:12 |
| falcojr | we don't really document the seed dir...I always thought of it as an implementation detail...not something we officially support | 19:12 |
| meena | blackboxsw: it was drowned out in the noise: https://gist.github.com/7a4f6b33b428b15892945b62a04ed8ee | 19:13 |
| meena | oh, right | 19:16 |
| blackboxsw | BTW meena are you running this on ec2? or some other cloud? I had (an incorrect?) memory that FreeBSD didn't/can't use ds-identify to artifically limit datasource selection in early boot right? | 19:16 |
| meena | i never understood what the metadata is there for anyway | 19:16 |
| meena | blackboxsw: right now, I'm mostly testing locally with libvirt/nocloud | 19:16 |
| meena | not sure how I can fake I'm on EC2 on Libvirt | 19:16 |
| meena | blackboxsw: but, as soon as I have more useful stuff that needs testing, I'll move to real clouds. Most people have offered me free access | 19:17 |
| minimal | blackboxsw: "Both files are required to be present for it to be considered a valid seed ISO." - but the /var/lib/cloud/seed/nocloud-net/ directory is a directory, not an ISO ;-) | 19:17 |
| meena | jrm: did you catch that ^ ? | 19:18 |
| meena | I'll build a small script to build a testing scenario for you | 19:18 |
| blackboxsw | +1. It might make sense for your own sense of well-being if in your libvirt/nocloud environment if you add a custom config /etc/cloud/cloud.cfg,d/95-just-usenocloud.cfg which contains: | 19:18 |
| blackboxsw | datasource_list: [NoCloud, None] | 19:18 |
| meena | blackboxsw: I've had that kinda thing fail in the past lol | 19:18 |
| blackboxsw | it'll ease testing for BSD images so you don't have to wait for all the other datasource detection logic in python to retry and timeout | 19:18 |
| meena | well, with hetzner, to be fair, but still | 19:19 |
| minimal | meena: "Most people have offered me free access" - lucky you! | 19:19 |
| blackboxsw | fair pt. | 19:19 |
| jrm | meena: Will check out the history when I get a chance. | 19:19 |
| meena | also, that was pre ds-identify hacks | 19:19 |
| meena | jrm: I'll just summarize it in a small shell script for you ;) | 19:19 |
| jrm | meena: Cool, thanks. | 19:19 |
| minimal | blackboxsw: in the past I'd tried putting a network-config file in the seed directory when using a seed-url as I was trying to figure out some way to set network-related stuff (i.e. vlan) that might be needed to get to seed-url in the first place....but of course it didn't work | 19:21 |
| blackboxsw | minimal: +1 on doc clarification. Probably at least a more prevalent warning from NoCloud datasource if it sees either just meta-data or just user-data but not both. We do log this type of ValueError if seedfromurl or filesystems with a CIDATA label are missing either meta-data or user-data. | 19:25 |
| meena | jrm: https://gist.github.com/igalic/d3b942400d01530aa7b75cf562589e50 | 19:28 |
| jrm | meena: Got it. Might not get to look today. | 19:31 |
| meena | jrm: works! | 19:33 |
| minimal | blackboxsw: interesting to see in cloud-init.log that after it says "Using seeded data from /var/lib/cloud/seed/nocloud it then still runs "blkid" to look for cidata CD | 19:41 |
| minimal | as guessing this might be priority related, e.g. if seed files AND a cidata CD both exist it then decides which to use? Going to test that next to see what happens | 19:43 |
| minimal | s/as/am/ | 19:43 |
| blackboxsw | minimal: right nocloud does try to supplement multiple nocloud viable datasources if found and merge each new seed type into the combined metadata, so you could have some config in priority order: nocloud seed data from DMI system-serial-number (in qemu case), /proc/cmdline for `ds=nocloud;<override_config>`, seed dirs on the filesystem, `seedfrom` in any currently discovered nocloud 'meta-data', then finally any CIDATA labeled disk. | 21:23 |
| blackboxsw | so nocloud supports multiple layers of merge overrides that could combine to give you the full picture of metadata provided from all viable source types | 21:24 |
| blackboxsw | ugh. falcojr I may want to steer clear of using %<varname>% in nocloud seed URL, given this undocumented feature https://github.com/canonical/cloud-init/commit/38422134fb64879cad81beb6cad15e538bdf87a6 | 22:06 |
| -ubottu:#cloud-init- Commit 3842213 in canonical/cloud-init "add support for '%s' in base of seed." | 22:06 | |
| blackboxsw | given that a seedfrom url could contain %s, it is thrown directly into a % format and a %dmi.varname% will inevitably complain that it doesn't see an int to format | 22:07 |
| falcojr | lol...fun feature | 22:08 |
| blackboxsw | ahh yeah. | 22:08 |
| falcojr | 💩dmi.varname💩 ? | 22:09 |
| meena | 👍 | 22:09 |
| blackboxsw | haha | 22:09 |
| blackboxsw | good ole' 2010 coming back to bite me | 22:10 |
| meena | and that's still there | 22:10 |
| blackboxsw | I'm sure grub's one-off shell environment won't adopt variable expansion of emojis.... right :)? | 22:10 |
| blackboxsw | time to deprecate. I'll put up a separate PR for that. This has to be done a better way. it's pretty arbitrary (and probably never used) | 22:12 |
| falcojr | yeah...even though it's undocumented, I'm concerned about a backwards incompatible change still | 22:13 |
| blackboxsw | ok. man, I could keep %dmi.<varname>% and just better handle the single '%s' alllowed if present in "seedfrom=http://url/%s?some_query_string=blah" | 22:15 |
| blackboxsw | ultimately the %s is just a token and we should have to use % formatting | 22:15 |
| blackboxsw | maybe I'll just tweak that on my PR for the moment and see round out a couple unittests to cover this case to better explain the madness | 22:16 |
| meena | blackboxsw: did you try taking it out and to see if any (integration) tests fail | 22:16 |
| blackboxsw | we should *not* have to use % formatting | 22:16 |
| blackboxsw | meena, this commit predated unittest or integration test coverage drives for the project. As it is currently no unittests even cover logic path. So I was going to add a couple there as their inexpensive to run. | 22:18 |
| blackboxsw | I was just looking into it as I was thinking of ammending our seedfrom value to better handle if someone didn't provide a trailing '/' at the end of the url | 22:20 |
| blackboxsw | but, looks like this may need to be a separate small PR | 22:21 |
| minimal | blackboxws: trying to figure out how with only seed *DIR* containing meta-data, user-data, and network-config and no other source for these (no cidata, etc) why the network-config which defines dhcp4: false, dhcp6: true ends up as being dhcp4: *true*, dhcp6: true (i.e. I only wanted v6, not v4 but v4 is also being enabled) | 23:48 |
| minimal | blackboxsw: ^^^ | 23:49 |
| minimal | I don't understand how/why this is happening | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!