=== falcojr1 is now known as falcojr [01:45] I was hoping to do two separate cloud-init runs. one for the auto-install and another for the configuration. [01:45] would this not be the simpler approach rather then try to have one run do too many bits [01:57] just having a play with the user-data section in auto install and will report back. [13:00] we testing SmartOS datasource, linux guest sucess reread datasource tty interface after reboot, freebsd read only cache data after reboot, why? [13:09] this require for add or reconfigure net/interfaces [14:58] https://paste.ubuntu.com/p/DHjPPCqXB5/ linux cache invalid, freebsd not, why? [15:30] linux have /run in tmp fs and delite cache content after reboot :) [17:15] rharper, smoser this is regarding #647. Sorry for approaching late. Just trying to understand what's next action on this. [17:17] is there any other approach we can take for LP: #1893770 [17:17] Launchpad bug 1893770 in cloud-init "Cloudinit resets network scripts to default configuration DHCP once Config Drive is removed after sometime" [Medium,In progress] https://launchpad.net/bugs/1893770 [17:24] vijayendra: as it is right now, the code has problems if ds-identify isn't used. [17:26] in that case it may resume from a cached pickle that is *not* the right platform. [17:27] what i would like to see changd is to have the 'check_instance_id()' respected if it is present [17:27] and ideally for the datasource to validate if it is on the right platform. [17:28] in order to do that, we'd want to add a "check_platform" like function to each of the datasources, that did basically what ds-identify does. [17:30] that part is fairly significant. [17:31] but the point being that in cloud-init we "know" that we are on google compute based on 'GoogleCloud-' in dmi information. [17:31] we should not resume from a GCE datasource if we are not on GoogleCloud [17:32] and we should not resume from a Azure datasource if we *are* on GCE [17:33] with ds-identify, and your check of "configured datasources", you kind of get that. but only becauase ds-identify set that datasource list. [17:33] and ds-identify isn't required [20:56] <__bw> hello - trying to debug cloud-init on a lxd image, cloud-init is installed in the image but i am not seeing the user data come through when launching. what datasource would lxd containers be using? [21:08] __bw: NoCloud, you should see /var/lib/cloud/seed/nocloud-net/user-data; I typically add user-data to lxc instances like this: lxc init ubuntu-daily:focal f6; sleep 1; lxc config set f6 user.user-data "$(cat test-user-data)" [21:12] <__bw> ty @rharper [21:12] This is my common pattern, to do it all in one command: lxc launch ubuntu-daily:focal f6 -c user.user-data="$(cat test-user-data)" [21:13] Odd_Bloke: I wasn't sure lxc launch would accept the config; interesting [21:14] Yeah, it's handy [21:15] (Works for user.network-config too.) [21:18] neat [21:42] <__bw> not getting any data inside the seed dir unfortunately -- this is a home-grown rhel image, with cloud-init installed. is there anything else needed to ensure the user-data makes it through? [21:48] I believe that there is configuration on images which causes things to be populated. [21:50] <__bw> i see in the logs, that cloud-init is checking the nocloud datasource but not finding anything [21:51] <__bw> ah it may be the lxd metadata.yaml [21:51] Look for the Context heading in https://linuxcontainers.org/lxd/docs/master/image-handling.html, it's the templates I'm referring to. [21:52] I don't know if lxd has default templates it uses, but I do know that Ubuntu ships templates for our images, you can see them here, for example: http://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-lxd.tar.xz [21:53] <__bw> yeah probably need to slip something similar in the image minting process for rhel, thanks