minimalmeena: I'm sure I've done that in the past00:24
minimalwhat does the cloud-init.log show? generally when using NoCloud I see in the log it checking for that file00:26
minimalas well as a version in nocloud-net00:26
meenaminimal: it's checking for that file, reading that file, and then, apparently, ignoring that file.00:36
minimalmeena: you're right, I'm seeing the same01:32
* meena blames blackbox08:45
* dch waves to meena12:19
dchalso if you have OpenBSD questions just @ me, I have some of them over there (gestures vaguely downwards)12:22
meenadch: I need someone to create a port for cloud-init and cloud-init-devel13:02
dchon OpenBSD ?13:02
dchwe should probably ask an OpenBSD person on masto.13:02
meenadch: yeah13:02
dchmeena: its not going to be me, I can't be bothered re-learning cvs13:03
dchhttps://github.com/exoscale/openbsd-cloud-init ;-) add another CI rewrite to the  list13:04
meenadch: i reckon you've seen https://reviews.freebsd.org/D3747913:06
dchand you know of cperciva's ones, and jmg's one also ?13:07
dchwith illustrious names like these, I feel compelled to write my own one in the most obscure language I can think of13:07
dchprobably some ocaml derivative would do13:07
dchmeena: btw do you know how to get c-i to produce an actual log file on FreeBSD?13:08
dchI see it in console log, but not in its nice happy own log13:08
meenadch: jrm and I fixed that in net/cloud-init-devel13:09
dchoh cool13:09
dchso I just use the -devel port13:09
dchglad I asked :-)13:09
-ubottu:#cloud-init- Commit 63c72b0 in FreeBSD/freebsd-ports "net/cloud-init-devel: Update and fix config file installation"13:11
meenaI think we'll have to port that back to net/cloud-init as well13:12
meenacuz it's the right way to do it13:12
dchIMO 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 port13:13
dchmeena: reading that its just the logging.cfg that was never copied across? or does it use upstreamed c-i chnages?13:14
dchi.e. if i drop 05_logging.cfg onto net/cloudinit does that work?13:15
dchthe .sample files look identical13:17
meenajust remove the .sample extension13:18
dchI just tested on the non-devel port, it also works13:21
dchso I can slam that file into the builds and finally have both logs and debugging output13:21
dchthank-you again meena !13:21
meenawe'll get half of IPv6 soon in net/cloud-init-devel13:21
dchfeel free to @ me whenever you need it, I can test it on OCI & Equinix as required13:26
meenathank 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
meenablackboxsw: didn't mean to mention you directly :P18:59
meenabut, yeah, no idea how to use /var/lib/cloud/seed/ directly19:00
blackboxswahh then, msg properly received :).    19:01
blackboxswMeena/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
blackboxswAny 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
falcojrblackboxsw: No concern from me. That's my preference anyhow19:04
meenablackboxsw: same19:04
blackboxswIt's probably trying to be 'too flexible' for cloud-init to allow distro-specific DMI keys anyway19: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: value19:06
blackboxswok. 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> support19:07
blackboxswthx 19:07
blackboxswI 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 directory19:09
blackboxsw.... and that cloud-init didn't do a good job of reporting a warning about the absence of meta-data or something19:10
meenablackboxsw: wait, i need meta-data too?19:10
meenalemme check19: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.html19:12
blackboxswthe optional files that could be provided are network-config and vendor-data19:12
blackboxswThat statement should probably be more noticeable  on the docs page19:12
falcojrwe don't really document the seed dir...I always thought of it as an implementation detail...not something we officially support19:12
meenablackboxsw: it was drowned out in the noise: https://gist.github.com/7a4f6b33b428b15892945b62a04ed8ee19:13
meenaoh, right19:16
blackboxswBTW 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
meenai never understood what the metadata is there for anyway19:16
meenablackboxsw: right now, I'm mostly testing locally with libvirt/nocloud19:16
meenanot sure how I can fake I'm on EC2 on Libvirt19:16
meenablackboxsw: but, as soon as I have more useful stuff that needs testing, I'll move to real clouds. Most people have offered me free access19:17
minimalblackboxsw: "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
meenajrm: did you catch that ^ ?19:18
meenaI'll build a small script to build a testing scenario for you19: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
blackboxswdatasource_list: [NoCloud, None]19:18
meenablackboxsw: I've had that kinda thing fail in the past lol19:18
blackboxswit'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 timeout19:18
meenawell, with hetzner, to be fair, but still19:19
minimalmeena: "Most people have offered me free access" - lucky you!19:19
blackboxswfair pt.19:19
jrmmeena: Will check out the history when I get a chance.19:19
meenaalso, that was pre ds-identify hacks19:19
meenajrm: I'll just summarize it in a small shell script for you ;)19:19
jrmmeena: Cool, thanks.19:19
minimalblackboxsw: 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 work19:21
blackboxswminimal: +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
meenajrm: https://gist.github.com/igalic/d3b942400d01530aa7b75cf562589e5019:28
jrmmeena: Got it.  Might not get to look today.19:31
meenajrm: works!19:33
minimalblackboxsw: 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 CD19:41
minimalas 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 happens19:43
blackboxswminimal: 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
blackboxswso nocloud supports multiple layers of merge overrides that could combine to give you the full picture of metadata provided from all viable source types21:24
blackboxswugh. 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/38422134fb64879cad81beb6cad15e538bdf87a622:06
-ubottu:#cloud-init- Commit 3842213 in canonical/cloud-init "add support for '%s' in base of seed."22:06
blackboxswgiven 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 format22:07
falcojrlol...fun feature22:08
blackboxswahh yeah.22:08
falcojr💩dmi.varname💩 ?22:09
blackboxswgood ole' 2010 coming back to bite me22:10
meenaand that's still there22:10
blackboxswI'm sure grub's one-off shell environment won't adopt variable expansion of emojis.... right :)?22:10
blackboxswtime 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
falcojryeah...even though it's undocumented, I'm concerned about a backwards incompatible change still22:13
blackboxswok. 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
blackboxswultimately the %s is just a token and we should have to use % formatting22:15
blackboxswmaybe 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
meenablackboxsw: did you try taking it out and to see if any (integration) tests fail22:16
blackboxsw we should *not* have to use % formatting22:16
blackboxswmeena, 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
blackboxswI 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
blackboxswbut, looks like this may need to be a separate small PR22:21
minimalblackboxws: 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
minimalblackboxsw: ^^^23:49
minimalI don't understand how/why this is happening23:49

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!