=== cpaelzer_ is now known as cpaelzer [15:04] Trying NoCloud seed URLs for the first time - fetching metadata and user-data from URL worked but not sure that handling of /var/lib/cloud/seed/nocloud-net/network-config worked as expected [15:06] logfile shows debug entry: "Seed from http:// not supported by DataSourceNoCloud [seed=None][dsmode=net] [15:17] you cannot seed network form nocloud-net [15:17] try /var/lib/cloud/seed/nocloud [15:18] minimal: https://asciinema.org/a/145772 [15:42] ok, changed to use the nocloud dir rather than nocloud-net and same debug message appears [15:44] your "video" is about seeding from ISO/FAT cidata, which I've been successfully using for more than a year. Now I'm testing http/https seed urls and its the network config part (not the metadata/user-data fetch) that appears to be the issue [15:47] basically in /var/lib/cloud/seed/nocloud/network-config I'm specifying both IPv4 and IPv6 DHCP but in the /e/n/i created it only specifies IPv4 DHCP [16:15] oh. yeah, you can't seed network data over a sedurl [16:16] that makes reasonable sense. [16:17] you definitely could do the whole ephemeral dhcp idea as is done on other platforms (digital ocean, ec2) [16:17] but that isn't present to my knowledge on nocloud [16:18] noclodu is a much more generic "platform". [16:19] i think what you're after is reasonable but needs implementation. [16:32] smoser: not trying to do network config over http - try to do it via file on filesystem [19:24] minimal: that should work . i think. I think i actually tested taht recently. [19:25] i'm not sure about eni writing... i suspect you're just getting the deault "dhcp on eth0" behavior, ratehr than explicitly writing dhcp for ipv4 [19:26] smoser: yeah, looks like its coming from generate_fallback_config which only handles IPv4 DHCP, no IPv6 (for example) [19:27] so currently no way to seed metadata & user-data via URLs on a IPv6-only network for instance [19:28] it seems like that shoudl work. [19:35] it loads the file ok, it just doesn't seem to use it [19:36] and so then the fallback network confing kicks in and generates e/n/i with just v4 DHCP [19:37] minimal: https://gist.github.com/smoser/54aef9c50abf53b2dc686d51c2a45216 [19:37] that is just something i dumped... found a conversation from awhile ago. it isn't 100% relevant, but might helpp you along the way. [19:40] I haven't yet tried passing seed info via cmdline [19:40] how were you doing it ? [19:41] just setting seedurl in /etc/cloud/cloud.cfg and creating a /var/lib/cloud/seed/nocloud/network-config file [19:43] i'd have to look at code, i dont really remember. [19:43] looking at DataSourceNoCloud.py I notice: "# Check to see if the seed dir has data." and immediately after that it defines "user-data" and "meta-data" as required but "network-config" as optional, which implies if the 2 required values are not specified then it will ignore the "network-config" setting [19:43] but maybe the lxd approach there can still help you. much faster than other ways of iterating. [19:43] I'll try that next to see if it changes behaviour [19:50] falcojr: for the single JSON schema PR I have up. I'm thinking we probably don't need the Paths.schema_dir if we aren't going to support composite schema parts as separate files [19:50] I agree [19:52] ok falcojr thoughts on Paths.schema_path vs static in cloudinit/settings.py or not worth the additional attribute and upgrade from pickle support? [19:53] I'm ok with a static path, but I think either way is fine [19:54] smoser: should the cmdline specify nocloud or nocloud-net? [20:25] smoser: passing via cmdline doesn't work here as (initramfs) init appears to strip entry once it sees the semicolon [21:05] hi. new cloud-init user here. i want to get the contents of 'v1.region' into a file on first boot. what's the right approach? [21:06] so far i've tried 'write_files' and 'runcmd' but both have resulted in the literal '{{ v1.region }}' in the file instead of the resolved value [21:07] apathor, welcome. double checking now. What's your cloud-config user-data? [21:08] It should start with ## template: jinja [21:09] ## template: jinja [21:09] #cloud-config [21:09] write_files: [21:09] - path: /home/yep [21:09] content: '{{v1.region}}' [21:10] https://gist.github.com/apathor/31e3c777649327b167dbda60051820e5 [21:10] the above works for me on lxc: lxc launch ubuntu-daily:focal myname -c user.user-data="$(cat test.yaml)" [21:10] apathor you are missing #cloud-config as the 2nd line [21:10] ah! thanks! [21:10] no worries thanks for the question [21:11] I would like us to extend cloud-init devel schema --annotate --system to handle ## template: jinja headers and report errors. Right now it only handles user-data that starts with #cloud-config. But, future us will better tell you the line failing in user-data schema. [21:12] couple weeks and we'll be there :/ [21:12] TBH i saw '#cloud-config' in example documents and didn't realize it was a meaningful header [21:13] for sure, some docs/example don't contain it. You'd see logs in /var/log/cloud-init.log saying that the userdata part-001 was ignored or skipped I think (saying cloud-init didn't think it could do anything with a non-#cloud-config part) [21:14] we try to capture docs here if helpful. https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html If you see some that don't have the header or seem confusing don't hesitate to point out bogus docs to us (or even better provide a PR at github.canonical.com/cloud-init). [21:17] thank you [21:51] Hey quick question. Trying to boot an ubuntu 20.04.03 (irrelevant I hope) image, and append to the authorized_keys on the command line. I have a workaround to do it by templating the user-data file, but wanted to see if I could append (not replace) a public key by typing on the kernel commandline [21:51] I'll be idling, thanks :) [23:29] follow up question - can jinja templates be used in /etc/cloud/cloud.cfg.d/ files or just user-data?