=== cpaelzer__ is now known as cpaelzer
=== vrubiolo1 is now known as vrubiolo
[16:04] <otubo> Guys, I'm leaving for my vacation, my PR will probably get stale, but I'll work on that when I'm back (which will be Jan/4th).
[16:05] <otubo> Happy holidays to the cloud-init family. Thanks for all the reviews :) Hope we can have fun again next year.
[16:11]  * rharper waves 
[17:09] <blackboxsw> otubo: take care!
[17:09]  * blackboxsw wonders about turning off our stale PR checker for the Holiday at end of next week :) should be pretty quiet around here
[17:10] <powersj> land everything then leave :P
[17:10] <blackboxsw> good point. I'll have falcojr do that with his new commit rights :)
[17:11] <blackboxsw> .... and have him plan to spend just a bit of time during his vacation fixing things :)
[17:11] <blackboxsw> falcojr:  landed https://github.com/canonical/pycloudlib/pull/77
[17:41] <falcojr> push a huge change right as I leave on Friday...what could go wrong?
=== ijohnson is now known as ijohnson|lunch
[18:45] <AU-S2S> Greetings!
[18:45] <AU-S2S> I'm working on a cloud-config to launch the stock Debian ami-070f235fd371de8e4, but I need to add a key to the admin user.
[18:45] <AU-S2S> The admin user pre-exists in the image. Would the proper syntax/yaml be:
[18:45] <AU-S2S> users:
[18:45] <AU-S2S>   - name: admin
[18:45] <AU-S2S>     ssh_authorized_keys:
[18:45] <AU-S2S>        - < key >
[18:45] <AU-S2S> Would this then just UPDATE the user?
[18:46] <AU-S2S> Sorry - This is on EC2...
[18:46] <meena> i would say: yes
[18:47] <AU-S2S> :) TY!
[18:49] <AU-S2S> Cloud-init is different than ignition which is what were were using for CoreOS.  Which there was a delta document.
[18:49] <AU-S2S> ^^ word - Wish.
=== ijohnson|lunch is now known as ijohnson
[22:05] <stephan48> hi, before i am searching for another hour... is there a solution for nocloud-net to pass in network config? i only see the ENI format
[22:56] <rharper> stephan48: are you attempting to pull config from remote or can you supply the nocloud datasource in the target filesystem or iso ?
[22:58] <stephan48> remote
[22:58] <rharper> if you are creating a nocloud iso datasource, you can put in a network-config file where you put user-data/meta-data files ... and you can use network-config v1 or v2;  note that you just need to omit the top-level 'network' key; network-config file is expected to
[23:00] <rharper> stephan48: I believe if you put up a network-config file where you're hosting your user-data/meta-data files it should fetch that as well
[23:01] <stephan48> no
[23:01] <stephan48>  https://github.com/number5/cloud-init/blob/master/cloudinit/sources/DataSourceNoCloud.py#L161 and https://github.com/number5/cloud-init/blob/00dbc1447bbf8ecf611653a1af50af958ac5aeb4/cloudinit/util.py#L814
[23:02] <stephan48> sry should have mentioned that i looked into the code already and just wanted confirmation that i am not blind
[23:02] <stephan48> in the debian buster version the vendor-data is not even in(did not check backports yet)
[23:03] <rharper> oh, usually talking upstream here ...  what version is present ?
[23:03] <stephan48> 20.2-2~deb10u1 in buster and buster-backports
[23:04] <stephan48> strange that its the same in both dists
[23:05] <stephan48> according to code the only source can be indeed files
[23:05] <stephan48> but mh.
[23:05] <stephan48> thinking about this I can integrate it
[23:06] <stephan48> if i ditch the nocloud for local sourcing
[23:06] <stephan48> i control the image installation after all... i am launching a debian-installer in which i do an automated full disk encrypted install
[23:07] <stephan48> i was just hoping to run the cloud-init handling inside the running os... for no apparrent reason
[23:07] <rharper> network-config typically is provided at local time, to configure the networking; in some cases (datasources) we bring up ephemeral networking (ie, dhcp on an interface and attempt to fetch network config);  I thought we had discussed/worked on NoCloud doing this; but I don't see that in the code though
[23:07] <stephan48> yea
[23:07] <stephan48> for Hetzner its in the code
[23:07] <rharper> y
[23:07] <stephan48> with an Ephemeral APIPA
[23:07] <stephan48> cloud-init is a fascinating piece of software :)
[23:08] <rharper> hehe, indeed
[23:10] <stephan48> learned a shit ton the past week. i went the long way around... injecting cloud-init user data into hetzner which downloads a ipxe, that bootstraps the debian-installer for preparing the disks, all with a bit of pingpong between the Hetzner API, a small App on my side. still needs to bring up the vpn automatically throu
[23:11] <rharper> nice
[23:12] <stephan48> so technically i could make the preseed generate a small partition with the cloud-init files for the finished VM and populate it at the end of setup from my API, but then i could aswell drop the required config directly into /etc/cloud/cloud.cfg.d/ as far as i understand
[23:12] <stephan48> theres no real benefit from nocloud at that point, or am I missing something?
[23:13] <rharper> if you can modify the target filesystem, there's no need for the partition , no
[23:13] <rharper> for NoCloud, putting things at /var/lib/cloud/seed/nocloud-net/{user-data,meta-data,network-config}  will do the trick;
[23:14] <stephan48> ah nice
[23:14] <rharper> for some cases where the rootfs is meant to be pristine; then storing the cloudconfig on secondary filesystem or partition is helpful
[23:14] <stephan48> yea
[23:14] <stephan48> usually if you restore/clone from an image
[23:14] <stephan48> you can just inject a second disk easily
[23:15] <stephan48> but then... i don't control the hypervisor... took me some time to figure out how to tell cloud-init to ignore Hetzner
[23:16] <stephan48> if not for the encrypted disk, i could go said cloning route here too
[23:16] <stephan48> but i don't like having multiple VMs with the same master keys
[23:17] <stephan48> and lets start another full reimaging run... see if i got all the last kinks out
[23:18] <stephan48> thanks! you gave me a lot of food for my thoughts, indeed the route with populating /var/lib/cloud/seed/nocloud-net/* will probably be the easiest one
[23:20] <rharper> stephan48: cool
[23:20] <stephan48> its quite fun seeing so many different software packages interacting