[01:45] <scahartner> I was hoping to do two separate cloud-init runs. one for the auto-install and another for the configuration.
[01:45] <scahartner> would this not be the simpler approach rather then try to have one run do too many bits
[01:57] <scahartner> just having a play with the user-data section in auto install and will report back.
[13:00] <faa> we testing SmartOS datasource, linux guest sucess reread datasource tty interface after reboot, freebsd read only cache data after reboot, why?
[13:09] <faa> this require for add or reconfigure net/interfaces
[14:58] <faa> https://paste.ubuntu.com/p/DHjPPCqXB5/ linux cache invalid, freebsd not, why?
[15:30] <faa> linux have /run in tmp fs and delite cache content after reboot :)
[17:15] <vijayendra> rharper, smoser this is regarding #647. Sorry for approaching late. Just trying to understand what's next action on this.
[17:17] <vijayendra> is there any other approach we can take for LP: #1893770
[17:24] <smoser> vijayendra: as it is right now, the code has problems if ds-identify isn't used.
[17:26] <smoser> in that case it may resume from a cached pickle that is *not* the right platform.
[17:27] <smoser> what i would like to see changd is to have the 'check_instance_id()' respected if it is present
[17:27] <smoser> and ideally for the datasource to validate if it is on the right platform.
[17:28] <smoser> 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] <smoser> that part is fairly significant.
[17:31] <smoser> but the point being that in cloud-init we "know" that we are on google compute based on 'GoogleCloud-' in dmi information.
[17:31] <smoser> we should not resume from a GCE datasource if we are not on GoogleCloud
[17:32] <smoser> and we should not resume from a Azure datasource if we *are* on GCE
[17:33] <smoser> 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] <smoser> 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] <rharper> __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] <Odd_Bloke> 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] <rharper> Odd_Bloke: I wasn't sure lxc launch would accept the config; interesting
[21:14] <Odd_Bloke> Yeah, it's handy
[21:15] <Odd_Bloke> (Works for user.network-config too.)
[21:18] <rharper> 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] <Odd_Bloke> 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] <Odd_Bloke> 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] <Odd_Bloke> 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