| 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:45 |
| ancienttoilet | however, I am not sure where to put or how to tell cloud-init to deploy that yml file | 13:46 |
| minimal | you provide that as user-data when you create the VM | 13:50 |
| minimal | where are you deploying? to a specific cloud provider? to a local hypervisor-based VM? | 13:51 |
| ancienttoilet | hey minimal | 14:11 |
| ancienttoilet | I am trying to deploy it locally really | 14:11 |
| ancienttoilet | and using lxd | 14:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| ancienttoilet | and the .yml config is the user-data right? | 14:17 |
| minimal | yes | 14:17 |
| 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:18 |
| ancienttoilet | I guess I have the basics figured now | 14:40 |
| ancienttoilet | one more question | 14:40 |
| 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:41 |
| ancienttoilet | https://pastebin.com/XwD0dvN8 | 14:42 |
| 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 | 16:04 |
| 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:49 |
| 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:51 | |
| OutOfService | hi | 17:55 |
| 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... | 17:58 |
| 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:09 |
| blackboxsw | as dbungert mentioned, best to continue the installer conversation over in #ubuntu-server | 18:10 |
| blackboxsw | thx dbungert | 18:10 |
| OutOfService | thanks very much!! | 18:13 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:43 |
| 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:46 |
| blackboxsw | so, not ideal if we don't have official BSD images in ec2/azure with cloud-init already installed | 19:47 |
| falcojr | yeah, that feels excessive to me | 19:48 |
| 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 | 19:51 |
| meena | blackboxsw: who do we need to talk to fix that? | 20:04 |
| meena | actually, i probably know | 20:05 |
| meena | https://freshbsd.org/freebsd/src/branch/main?q=azure | 20:06 |
| meena | looks like lwhsu@ does azure stuff on behalf of the freebsd foundation | 20:07 |
| meena | https://github.com/freebsd/freebsd-src/blob/main/release/tools/azure.conf | 20:11 |
| 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:16 |
| 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:19 | |
| 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:20 |
| blackboxsw | I mean this'll be cloud-init 23.3 as that functionality just landed now. | 20:21 |
| meena | blackboxsw: yes. it seems to work! | 20:26 |
| meena | I just say I'm surprised myself;) | 20:26 |
| blackboxsw | sweet! | 20:34 |
| 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:36 |
| meena | I've also made it easy for the service to be removed, in case someone prefers that | 20:37 |
| blackboxsw | good deal. | 20:42 |
| 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:44 |
| minimal | blackboxsw: some of the BSDs (OpenBSD for example) tend to use doas rather than sudo | 20:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| blackboxsw | agreed. one or the other. sensible fallback when sudo doesn't exist... and a hard fail if neither sudo nor doas | 20:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!