[15:04] <minimal> 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] <minimal> logfile shows debug entry: "Seed from http://<relevant url> not supported by DataSourceNoCloud [seed=None][dsmode=net]
[15:17] <smoser> you cannot seed network form nocloud-net
[15:17] <smoser> try /var/lib/cloud/seed/nocloud
[15:18] <smoser> minimal: https://asciinema.org/a/145772
[15:42] <minimal> ok, changed to use the nocloud dir rather than nocloud-net and same debug message appears
[15:44] <minimal> 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] <minimal> 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] <smoser> oh. yeah, you can't seed network data over a sedurl
[16:16] <smoser> that makes reasonable sense.
[16:17] <smoser> you definitely could do the whole ephemeral dhcp idea as is done on other platforms (digital ocean, ec2)
[16:17] <smoser> but that isn't present to my knowledge on nocloud
[16:18] <smoser> noclodu is a much more generic "platform".
[16:19] <smoser> i think what you're after is reasonable but needs implementation.
[16:32] <minimal> smoser: not trying to do network config over http - try to do it via file on filesystem
[19:24] <smoser> minimal: that should work . i think. I think i actually tested taht recently.
[19:25] <smoser> 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] <minimal> smoser: yeah, looks like its coming from generate_fallback_config which only handles IPv4 DHCP, no IPv6 (for example)
[19:27] <minimal> so currently no way to seed metadata & user-data via URLs on a IPv6-only network for instance
[19:28] <smoser> it seems like that shoudl work.
[19:35] <minimal> it loads the file ok, it just doesn't seem to use it
[19:36] <minimal> and so then the fallback network confing kicks in and generates e/n/i with just v4 DHCP
[19:37] <smoser> minimal: https://gist.github.com/smoser/54aef9c50abf53b2dc686d51c2a45216
[19:37] <smoser> 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] <minimal> I haven't yet tried passing seed info via cmdline
[19:40] <smoser> how were you doing it ?
[19:41] <minimal> just setting seedurl in /etc/cloud/cloud.cfg and creating a /var/lib/cloud/seed/nocloud/network-config file
[19:43] <smoser> i'd have to look at code, i dont really remember.
[19:43] <minimal> 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] <smoser> but maybe the lxd approach there can still help you. much faster than other ways of iterating.
[19:43] <minimal> I'll try that next to see if it changes behaviour
[19:50] <blackboxsw> 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] <falcojr> I agree
[19:52] <blackboxsw> 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] <falcojr> I'm ok with a static path, but I think either way is fine
[19:54] <minimal> smoser: should the cmdline specify nocloud or nocloud-net?
[20:25] <minimal> smoser: passing via cmdline doesn't work here as (initramfs) init appears to strip entry once it sees the semicolon
[21:05] <apathor> 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] <apathor> 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] <blackboxsw> apathor, welcome. double checking now. What's your cloud-config user-data?
[21:08] <blackboxsw> It should start with ## template: jinja 
[21:09] <blackboxsw> ## template: jinja
[21:09] <blackboxsw> #cloud-config
[21:09] <blackboxsw> write_files:
[21:09] <blackboxsw>  - path: /home/yep
[21:09] <blackboxsw>    content: '{{v1.region}}'
[21:10] <apathor> https://gist.github.com/apathor/31e3c777649327b167dbda60051820e5
[21:10] <blackboxsw> the above works for me on lxc:     lxc launch ubuntu-daily:focal myname -c user.user-data="$(cat test.yaml)"
[21:10] <blackboxsw> apathor you are missing #cloud-config as the 2nd line
[21:10] <apathor> ah! thanks!
[21:10] <blackboxsw> no worries thanks for the question
[21:11] <blackboxsw> 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] <blackboxsw> couple weeks and we'll be there :/
[21:12] <apathor> TBH i saw '#cloud-config' in example documents and didn't realize it was a meaningful header
[21:13] <blackboxsw> 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] <blackboxsw> 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] <apathor> thank you
[21:51] <Vaelatern> 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] <Vaelatern> I'll be idling, thanks :)
[23:29] <apathor> follow up question - can jinja templates be used in /etc/cloud/cloud.cfg.d/ files or just user-data?