=== tds0 is now known as tds
=== bashfulrobot_ is now known as bashfulrobot
=== fyx_ is now known as fyx
=== andrein_ is now known as andrein
=== jdoss_ is now known as jdoss
=== ]42[ is now known as [42]
[13:41] <unix_> hi
[13:41] <unix_> magyarul, english, deutsch?
[13:41] <unix_> on smartos
[13:41] <unix_> "customer_metadata": {
[13:42] <unix_>     "user-script": "echo 'IPV6_DEFAULTGW=2001:4178:6:1416::1' >> /etc/sysconfig/network-scripts/ifcfg-net0"
[13:42] <unix_>   }
[13:42] <unix_> warum nicht funktioniert?
[13:42] <unix_> host: smartos
[13:43] <unix_> vm: centos
[13:53] <unix_> [   46.241951] cloud-init[1401]: 2021-03-04 13:53:21,339 - util.py[WARNING]: Failed running /var/lib/cloud/scripts/per-boot/01_smartos_vendor_data.sh [127]
[13:54] <unix_> [   46.249815] cloud-init[1401]: 2021-03-04 13:53:21,348 - cc_scripts_per_boot.py[WARNING]: Failed to run module scripts-per-boot (per-boot in /var/lib/cloud/scripts/per-boot)
[13:54] <unix_> [   46.254142] cloud-init[1401]: 2021-03-04 13:53:21,352 - util.py[WARNING]: Running module scripts-per-boot (<module 'cloudinit.config.cc_scripts_per_boot' from '/usr/lib/python3.6/site-packages/cloudinit/config/cc_scripts_per_boot.py'>) failed
[14:08] <unix_> problem solved.
[14:41] <Odd_Bloke> Glad to hear you solved it. :)
[14:45] <unix_> :D
[15:04] <Odd_Bloke> falcojr: https://github.com/canonical/cloud-init/pull/829 is ready for review; it's missing some testing docs, but is otherwise complete, I think.
[15:04] <Odd_Bloke> rharper: ^ is touching cloudinit.net, so of course your input would be great. :)
[15:09] <rharper> Odd_Bloke: sure
[15:32] <unix_> little problem is that you add the gateway every time you reboot
[15:32] <unix_> I only want to add it once
[15:36] <unix_> currently only works in this form:
[15:36] <unix_>   "customer_metadata": {
[15:36] <unix_>     "user-script": "echo BOOTPROTO=none > /etc/sysconfig/network-scripts/ifcfg-net0 && echo DEVICE=net0 >> /etc/sysconfig/network-scripts/ifcfg-net0  && echo HWADDR=92:9c:47:10:af:6b >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6ADDR=2001:4178:6:1416:62:116:187:84/64 >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo ONBOOT=yes >> /etc/sysconfig/network-scripts/ifcfg-net0
[15:36] <unix_>  && echo TYPE=Ethernet >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo USERCTL=no >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6_DEFAULTGW=2001:4178:6:1416::1 >> /etc/sysconfig/network-scripts/ifcfg-net0 && ifdown net0 && ifup net0"
[15:37] <unix_> which is ugly but it works
[15:38] <Odd_Bloke> unix_: I'm not sure I understand what you mean by "add the gateway every time you reboot"?  If it weren't added on every boot, it wouldn't be used, right?
[15:39] <unix_> the first
[15:39] <unix_> "user-script": "echo 'IPV6_DEFAULTGW=2001:4178:6:1416::1' >> /etc/sysconfig/network-scripts/ifcfg-net0"
[15:39] <unix_> enter each time you restart..
[15:40] <unix_> then it looks like this:
[15:40] <unix_> IPV6_DEFAULTGW=2001:4178:6:1416::1
[15:40] <unix_> IPV6_DEFAULTGW=2001:4178:6:1416::1
[15:40] <unix_> IPV6_DEFAULTGW=2001:4178:6:1416::1
[15:40] <unix_> etc
[15:42] <unix_> version 2 already works fine, don't add it more than once, just too long
[15:42] <unix_> there is definitely an easier method
[15:43] <Odd_Bloke> unix_: Aha, I think I understand: per-boot scripts are designed to run every boot; if you only want to configure that once per instance, then doing so in a per-instance script would perhaps be more appropriate?
[15:44] <unix_> what is the difference between user-script and user-data?
[15:45] <unix_> and bootcmd/runcmd?
[15:56] <Odd_Bloke> unix_: It looks like user-script is SmartOS-specific configuration, a shell script which is executed by cloud-init by default.
[15:57] <Odd_Bloke> bootcmd/runcmd would have to be specified as user-data, and the difference is when in the boot process they run; roughly: bootcmd runs early, runcmd runs late.
[16:01] <chillysurfer> question on cloud-init releases... when the upstream team creates a new release what effectively happens to the git repo? there's a git tag with just the version itself (e.g. `20.4.1`), and then there is an ubuntu/* tag for the release to ubuntu?
[16:02] <chillysurfer> but ignoring the ubuntu/* tag, the version tag release (standalone) is the indication in the git repo of a release?
[16:07] <unix_> thx!
[16:23] <xscori> Hi! Have a q. about writing shh public key to a different location than the usual user's home dir. sshd_config in the system is looking for keys at /etc/ssh/keys/
[16:23] <xscori> How can I tell cloud-init to use that location instead of inserting them into ~/.ssh/ ?
[16:23] <xscori> ssh*
[16:26] <stevenm> hey, so being new to cloud-init.   Do most prepared images with cloud-init support... use the information given on the first boot and then never look again?
[16:26] <stevenm> it's like a pseudo iso that's mounted right?
[16:51] <meena> stevenm: unless something so significant in the hardware changes that the cloud decides to change your servers id, the most significant work happens on the first boot
[16:51] <meena> there are modules that run on every boot, tho
[16:52] <stevenm> well in this circumstance I would be the cloud myself (proxmox)
[16:53]  * meena has never built a cloud with proxmox
[16:53] <stevenm> so I guess we'd set cloud-init options/files/etc against a VM.. boot it... then err 10 mins later?  unset them all
[16:53] <stevenm> then in theory if it (the VM) ever tries to look at cloud-init data again (e.g. on reboot) it'd find nothing
[16:54] <meena> the data is cached on disk
[16:54] <meena> we fall back to the cache (if that's been merged lol)
[16:54] <stevenm> whose disk? within the VM's own disks?
[16:54] <meena> yes
[16:55] <meena> you give the VMs disks they can write to?
[16:55] <stevenm> oh i got the impression cloud-init could be used as a one time thing... e.g. setting an IP on first boot
[16:55] <stevenm> but you're saying the IP on subsequent boots would re-check what it's mean to be according to cloud-init?
[16:56] <meena> it does that, but there are scenarios where we might need to look at the data again
[16:56] <meena> like when someone forces a re-run
[16:56] <stevenm> i.e. the user of that VM forces their VM to re-check cloud-init data?
[16:57] <stevenm> defo unsetting it then lol
[16:57] <stevenm> we just want to use this little 'cloud-init' thing to make sure customer VM's are accessible on their choice of network on first boot *only* - the rest they can configure themselves
[16:57] <meena> there are good reasons to do that sometimes, tho i prefer to just blow away the VM and get a new one
[16:57] <stevenm> other minor things are admittedly unavoidable like default users/pass's etc... but we're aiming for minimum effort
[16:58] <meena> disk resize
[16:58] <stevenm> you mean filesystem resize?
[16:58] <meena> yeah
[16:59] <stevenm> well that'll be up to the VM in question I guess
[16:59] <meena> usually, you build images with the smallest size possible, you put it into the VM and then not it and cloud-init resizes the file systems
[17:00] <stevenm> "not it" ?
[17:00] <meena> Boot it
[17:00] <stevenm> ah yeah
[17:01] <stevenm> i mean I guess something things (cloud-init or not) might do that anyway
[17:01] <stevenm> e.g. like when you the raspberry-pi OS image on a microSD... on first boot it'll grow
[17:02] <meena> i recently learned freebsd does that on its own on first boot, so i should build my images with /first-boot touched and see who gets there first
[17:44] <Odd_Bloke> chillysurfer: Correct, those tags indicate the release commit.  They should be signed and annotated, though I'm seeing that perhaps not all of them are currently.
[17:46] <Odd_Bloke> xscori: cloud-init doesn't handle non-default SSH key locations currently, unfortunately: it's complicated, and getting it wrong can have substantial security impacts.  So your best bet is to use `write_files` or `runcmd` to arrange things as they should be.
[17:47] <Odd_Bloke> stevenm: cloud-init runs at every boot of cloud instances, to detect whether or not this is a new instance (as well as to perform any per-boot configuration supplied by the user).  If it detects it is a new instance, it will re-run any per-instance actions, including network configuration.
[17:48] <Odd_Bloke> (If it doesn't run at every boot, then instances launched from images captured from instances will not behave correctly: they won't apply per-instance configuration despite the fact this is a new instance.)
[17:49] <Odd_Bloke> By default, though, cloud-init will not reconfigure networking on every boot.  There are exceptions to this: e.g. EC2 Classic (i.e. pre-VPC) instances get a new MAC address at every boot, so configuration written for the previous MAC address will not apply on subsequent boots.
[17:50] <Odd_Bloke> It's worth noting that if you unset the metadata in the cloud, cloud-init may detect future boots as new boots.
[17:51] <Odd_Bloke> stevenm: https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination breaks down this behaviour in more detail.
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson