[13:45] <ancienttoilet> Good afternoon. First time every using cloud-init and I am really confused
[13:45] <ancienttoilet> I wold like to automate the deployment of Landscape with it, here is the yml file https://raw.githubusercontent.com/canonical/landscape-scripts/main/provisioning/cloud-init.yaml
[13:46] <ancienttoilet> however, I am not sure where to put or how to tell  cloud-init to deploy that yml file
[13:50] <minimal> you provide that as user-data when you create the VM
[13:51] <minimal> where are you deploying? to a specific cloud provider? to a local hypervisor-based VM?
[14:11] <ancienttoilet> hey minimal 
[14:11] <ancienttoilet> I am trying to deploy it locally really
[14:11] <ancienttoilet> and using lxd
[14:12] <ancienttoilet> so I need to use lxd commands to deploy that yml file?
[14:12] <minimal> so then when you deploy the VM via LXD you use whatever mechanism the LXD tools have to specify user-data
[14:12] <ancienttoilet> I was expecting something like docker-compose . I was wrong :S
[14:13] <minimal> you must be running some cli tool to deploy the VM, right?
[14:13] <ancienttoilet> alright then, I will do the tutorial. 
[14:13] <ancienttoilet> what do you mean?
[14:13] <ancienttoilet> the host is debian
[14:13] <minimal> how are you creating the VM in LXD?
[14:13] <ancienttoilet> lxd handles containers
[14:14] <minimal> yes and it also handles VMs, I assumed you were creating a VM not a containers
[14:14] <ancienttoilet> I thought I could feed the .yml file to cloud-init just as you do for docker-composer
[14:14] <minimal> how are you creating the container/VM with LXD?
[14:14] <ancienttoilet> minimal: I understand. Well I am kinda confused atm
[14:14] <ancienttoilet> I haven't yet.
[14:15] <minimal> LXD containers are nothing to do with docker
[14:15] <ancienttoilet> I literally started exploring this project
[14:15] <ancienttoilet> minimal: I know. I just though cloud-init usage of a yml file would be similar to docker-compose.
[14:15] <ancienttoilet> my mistake
[14:16] <minimal> you use a LXD tool to create a LXD container or LXD VM, that tool should provide a way to specify user-data at the same time
[14:17] <ancienttoilet> and the .yml config is the user-data right?
[14:17] <minimal> yes
[14:18] <ancienttoilet> alright, I guess I have some readings to do before I even go ahead with this
[14:18] <ancienttoilet> thank you for now :)
[14:40] <ancienttoilet> I guess I have the basics figured now
[14:40] <ancienttoilet> one more question
[14:41] <ancienttoilet> how can I pass the proxy settings to cloud-init? I have it in /etc/environment but it is not liking it by the looks of it
[14:42] <ancienttoilet> https://pastebin.com/XwD0dvN8
[16:04] <minimal> ancienttoilet: that is nothing to do with cloud-init - cloud-init runs inside the ubuntu cloud image which this error shows has not even been downloaded yet
[17:49] <blackboxsw> ancienttoilet: right, check out this tutorial for cloud-init on launching LXD with user-data https://cloudinit.readthedocs.io/en/latest/tutorial/lxd.html. 
[17:51] <blackboxsw> and for proxy settings in cloud-init I don't think we've grown proper proxy config setup/automation given the state of this bug https://bugs.launchpad.net/cloud-init/+bug/1089405 (which has a workaround for you which may help)
[17:51] -ubottu:#cloud-init- Launchpad bug 1089405 in cloud-init "setting up system proxy via cloud-config might be nice" [Wishlist, Expired]
[17:55] <OutOfService> hi
[17:58] <OutOfService> so, i seems that there is a new way in order to deploy ubuntu, right? I'm used to use ipxe with http and simple config parameters for installing to my lab. Now I'm a little lost with cloud-init. Could please somebody help me to find some examples for installing ubuntu via (i)pxe and http, please? I don't know where top start.. there is no very much information at these days...
[18:09] <dbungert> OutOfService: I think this is more of an Ubuntu topic than a cloud-init one.  I suggest taking this to #ubuntu-server.  as a starting point, https://ubuntu.com/server/docs/install/autoinstall-quickstart has a bit about feeding autoinstall by way of cloud-init to the newer installers.
[18:09] <blackboxsw> OutOfService: seems like you are referring to Ubuntu autoinstall on live server/desktop images. https://ubuntu.com/server/docs/install/autoinstall  and https://ubuntu.com/server/docs/install/netboot-arm64 may be helpful. Cloud-init is used under the hood to allow for obtaining #cloud-config user-data during that boot process. The autoinstall:  key is largely ignored by cloud-init and passed through to the subiquity installer...   
[18:09] <blackboxsw> https://cloudinit.readthedocs.io/en/latest/reference/faq.html#autoinstall-preruncmd-postruncmd.
[18:10] <blackboxsw> as dbungert mentioned, best to continue the installer conversation over in #ubuntu-server
[18:10] <blackboxsw> thx dbungert 
[18:13] <OutOfService> thanks very much!!
[19:38] <blackboxsw> holmanb: I mentioned I'd look again at BSD images in clouds to see status/supportability from pycloudlib. As it stands, it looks like thefreebsdfoundation is a publisher of Azure images, but those images don't contain cloud-init by default. I think meena has mentioned https://bsd-cloud-image.org/ as typical base BSD image which can be converted and uploaded to clouds. 
[19:39] <blackboxsw> azure's BSD publisher images:  are as follows: 
[19:39] <blackboxsw> +FREEBSD_IMAGES = {
[19:39] <blackboxsw> +    "13.1": "thefreebsdfoundation:freebsd-13_2:13_2-release:13.1.0",
[19:39] <blackboxsw> +    "13.2": "thefreebsdfoundation:freebsd-13_2:13_2-release:13.2.0",
[19:39] <blackboxsw> +}
[19:39] <blackboxsw> ec2, on the otherhand seems to have an ec2 marketplace publisher "FreeBSD" which do contain cloud-init in images. I have a working example that I'd like to add to pycloudlib/examples
[19:39] <blackboxsw> https://aws.amazon.com/marketplace/seller-profile?id=92bb514d-02bc-49fd-9727-c474863f63da&ref=dtl_B0928XNW6D
[19:40] <blackboxsw> holmanb: and I've tested latest pycloudlib with your changes for custom username and we can directly provide known amis from ec2 BSD marketplace images and successfully interact w/ cloud-init there.
[19:43] <blackboxsw> strike that on ec2... it's running configinit too (like Azure images) https://www.daemonology.net/blog/2013-12-09-FreeBSD-EC2-configinit.html
[19:46] <blackboxsw> so I can put together a pycloudlib:examples/ec2.py  script that shows pkg install py39-cloud-init and rebooting into the test system.... but again it'd be injecting cloud-init after initial boot and rebooting into the 'clean' environment
[19:47] <blackboxsw> so, not ideal if we don't have official BSD images in ec2/azure with cloud-init already installed
[19:48] <falcojr> yeah, that feels excessive to me
[19:51] <blackboxsw> yeah, I think it's enough to say, pycloudlib supports unique AMIs from BSD when present and can interact with that VM using the desired custom username and related SSH pubkey/cert
[20:04] <meena> blackboxsw: who do we need to talk to fix that?
[20:05] <meena> actually, i probably know
[20:06] <meena> https://freshbsd.org/freebsd/src/branch/main?q=azure
[20:07] <meena> looks like lwhsu@ does azure stuff on behalf of the freebsd foundation 
[20:11] <meena> https://github.com/freebsd/freebsd-src/blob/main/release/tools/azure.conf
[20:16] <blackboxsw> yeah that may help if there are Azure images from thefreebsdfoundation: containing configured/enabled cloud-init by default, pycloudlib testing should be a breeze.
[20:19] <blackboxsw> meena: with your recent merges of https://github.com/canonical/cloud-init/pull/4209/files and https://github.com/canonical/cloud-init/pull/4182 does that mean things are well placed for ds-identify to quickly reduce possible datasources detected on BSD prior to any cloud-init python code getting involved trying to DataSource*._get_data() now?
[20:19] -ubottu:#cloud-init- Pull 4209 in canonical/cloud-init "setup: fix generation of init templates" [Merged]
[20:19] -ubottu:#cloud-init- Pull 4182 in canonical/cloud-init "BSD: add dsidentify to early startup scripts" [Merged]
[20:20] <blackboxsw> as in, BSD cloud-images can contain a configured  cloud-init  which will filter it's datasource discovery based on the outputs of ds-identify in early boot.
[20:21] <blackboxsw> I mean this'll be cloud-init 23.3  as that functionality just landed now.
[20:26] <meena> blackboxsw: yes. it seems to work!
[20:26] <meena> I just say I'm surprised myself;)
[20:34] <blackboxsw> sweet!
[20:36] <blackboxsw> that'll be a huge performance boost as folks publish BSD images to various clouds to allow them to  avoid having to tailor the image to a specific `datasource_list: [ Ec2 ]` or OpenStack etc
[20:37] <meena> I've also made it easy for the service to be removed, in case someone prefers that
[20:42] <blackboxsw> good deal.
[20:44] <blackboxsw> meena: do you know offhand if typical BSD images prefer to **not** have sudo installed? just wondering from expectations of cloud-init and pycloudlib integration tests .pycloudlib tries to use sudo when non-root user is the default user on an instance 
[20:44] <blackboxsw> and the BSD images I've seen in azure/ec2 don't have sudo installed by default
[20:44] <blackboxsw> it's something we'll have to be aware of if we want easy cloud image testing setup somewhere for BSD.
[20:45] <minimal> blackboxsw: some of the BSDs (OpenBSD for example) tend to use doas rather than sudo
[20:46] <meena> OpenBSD has a doas in Base, and for everyone else it's a contentious subject
[20:46] <minimal> I've been adapting my Alpine-specific patch to cloud-init to make it OS generic with the intention of submitting a PR for it soon (just need to write testcases)
[20:46] <minimal> my doas patch I mean
[20:47] <meena> I think the split is probably fifty 60% sudo, 25 su, rest doas
[20:47] <blackboxsw> TIL about doas thx.  so pycloudlib may need to grow a switch based on what utility to escalate permissions is available. specifically I'm thinking about things like our Instance.clean method https://github.com/canonical/pycloudlib/blob/main/pycloudlib/instance.py#L198-L212
[20:48] <meena> it would be cool if the choice was configurable, but as of yet, it's a runtime dependency, so it's a porter's opinion in that mix, too
[20:48] <blackboxsw> that'd be a blocker as many integration tests try to use "clean" before snapshotting images in clouds
[20:48] <blackboxsw> and then running through test cases for the base snapshotted image (with cloud-init upgraded to whatever we are testing)
[20:49] <blackboxsw> makes sense.
[20:49] <minimal> blackboxsw: I guess you'd have to run "which sudo", "which doas" etc or similar to decide which is available first
[20:50] <meena> seems easy enough
[20:50] <blackboxsw> yeah that's what I'm thinking too minimal.. though this particular ec2 marketplace image of BSD has neither sudo nor doas :)
[20:50] <blackboxsw> so I have to su ... .then pkg install X
[20:50] <meena> you'd probably not want both of those installed, and definitely not on a test system 
[20:52] <blackboxsw> agreed. one or the other. sensible fallback when sudo doesn't exist... and a hard fail if neither sudo nor doas