[00:07] <Guest44454> Good afternoon everyone, I am really struggling with cloud-init. Can I fire off some questions?
[00:07] <Guest44454> The struggle starts with me knowing absolutely 0 (zero) about it
[00:08] <Guest44454> But my boss has insisted we use it to spin up our servers in case of disaster
[00:37] <minimal> Guest44454: have you started by readings the docs? https://cloudinit.readthedocs.io/en/latest/
[13:53] <Guest38> Hello all, does cloud-init has support for lvm ? i don't see nothing mentioned on the documentation.
[13:59] <falcojr> Guest38: No, there's nothing for setting up or resizing anything LVM related
[14:26] <minimal> falcojr: growpart (from cloud-utils) does have some lvm support
[14:28] <minimal> Guest38: so far I've just added entries to run_cmd in user-data to run pvresize and lvextend
[14:30] <minimal> IMHO growing/resizing LVM is not a simple "one size fits all" method - typically I'd want the underlying partition grown to fill the disk and the PV on top of it also grown to fill the partition, but I would not want LVs automatically resized by cloud-init
[14:32] <minimal> falcojr: just checked, growpart can run "lvm pvresize" (I assume after partition has been grown)
[14:32] <falcojr> minimal: in cloud-init?
[14:33] <minimal> cloud-init typically calls cloud-utils' growpart
[14:34] <falcojr> yeah, but IIRC, we don't expose any options through cloud-init that work with LVM
[14:34] <minimal> depending on the user-data "growpart" mode setting
[14:35] <minimal> I just just pointing out that if growpart is triggered by cloud-init to grow a LVM partition it also will do a pvresize as well
[14:36] <minimal> so there's a limited degree of "implicit" support for LVM by viture of using growpart
[18:16] <blackboxsw> falcojr: just filed a review for discussion of on your pycloudlibe ec2 test instance launch approach https://github.com/canonical/pycloudlib/pull/188
[18:24] <falcojr> blackboxsw: "I'm testing this suggestion now". No problem if you want to keep going with it, but I can make the changes too
[18:25] <blackboxsw> falcojr: I'm just trying to make sure my suggestion doesn't actually break our use of pycloudlib :)
[18:26] <falcojr> blackboxsw: I see the param now in run_instances documentation (for some reason I didn't before), so I think it should work
[18:27] <blackboxsw> I think there may be a reason for post-launch IPV6 setup (because cloud-init's doesn't handle IPv6 via the EphermeralDHCPv4 local stage setup). But, maybe this is a non-issue for this iteration because we can specify both HttpProtocolIpv6='enabled' and HttpEndpoint='enabled'
[18:28] <blackboxsw> I'm not sure if omission of the HttpEndpoint setting will 'disable' ipv4 in this case
[18:29] <falcojr> blackboxsw: the one I'm setting in this PR only enables the IPv6 endpoint. v4 still lives too. I can't see how enabling it would break anything else
[18:29] <falcojr> (famous last words)
[19:07] <blackboxsw> spending my time today going through our cloud-config-user-groups.txt docs as they are not deployable without error :/
[20:19] <Guest44454> Morning all
[20:19] <Guest44454> I was talking yesterday about help with cloud-init on a bare metal local install
[20:20] <Guest44454> Can anyone help? My humble question is, how do I do it. I have read the docs (and gravely missed something) as I cannot see how cloud-init starts
[20:21] <Guest44454> ANy help with setting up a solution would be appreciated
[20:23] <meena> Guest44454: cloud-init starts on boot, however, it needs a data source that tells it what to do
[20:23] <Guest44454> Hi Meena
[20:24] <Guest44454> I understand that a 'nocloud' setup means I need to create my config file & place it in the /etc/cloud/ folder on my installation medium? (eg. /etc/cloud/cloud.cfg)
[20:24] <Guest44454> Is that correct?
[20:25] <meena> Guest44454: no
[20:26] <meena> NoCloud is either a filesystem or a available via HTTP: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[20:28] <Guest44454> Ok,
[20:28] <Guest44454> so,
[20:28] <blackboxsw> +1  meena thx. and additionally (and underdocumented) NoCloud can be seeded from /var/lib/cloud/seed/nocloud-net in an image per https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceNoCloud.py#L31    Generally the easiest check of how/whether cloud-init can detect your datasource is looking through the script ds-identify which tells cloud-init whether the environment in which it is running looks like 
[20:28] <blackboxsw> it might be viable
[20:29] <blackboxsw> ds-identify code is here: https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L836 specifically that function tells cloud-init whether it thinks it will discover NoCloud config details
[20:29] <meena> i think one other undocumented thing is that there's no general guidelines on how to do a bare-metal install with cloud-init
[20:30] <Guest44454> Here comes probably the noobiest question, please be kind: Where & when & how do I run that command? ds=nocloud[;key=val;key=val]
[20:30] <Guest44454> Thanks meena, thats the struggle I was thinking :(
[20:31] <Guest44454> Scenario: I am standing in front of new hardware, nothing on it, with a USB stick and ubuntu server
[20:31] <blackboxsw> meena/Guest44454 +1 I was thinking we should add this to our upcoming roadmap as well (we've tried carving out time for documentation overhaul, tutorials/howtos etc of which I feel this could be a part of what's needed)
[20:32] <Guest44454> blackboxsw I am happy to contribute my journey in this
[20:33] <Guest44454> Let me just confirm what I have done in the past:
[20:35] <Guest44454> I created my usb drive with ubunutu server, and a bash script on the drive itself. I installed Ubuntu then ran the bash script which updated, upgraded, created users from a called bash script & expired their passwords forcing password changes at login & installed all needed software
[20:35] <Guest44454> This works perfectly, but now we are looking to cloud-init
[20:37] <memyselfandubunt> Hello all, when installing from a mini.iso i get around 360 packages very minimal instalation(which is what i want), but if i install it from the ubuntu-live-server i get around 560 packages without selecting any package group, is it possible to overwrite this in the ubuntu-live-server install (siquibity?)?
[20:37] <minimal> Guest44454: generally you start with an OS image already configured with cloud-init enabled, write that to a disk and boot so that cloud-init does its stuff on 1st boot
[20:40] <Guest44454> Thanks minimal, this part I also guessed to be right. How do I get the already configured OS written to disk to boot? 'our disk images are +350Gb'
[20:41] <meena> Guest44454: is all of that 350G used??
[20:41] <Guest44454> Its our ERP server
[20:41] <meena> https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart
[20:41] <Guest44454> No, the hdd space is not full, but our image of working data is 350+ GB
[20:43] <Guest44454> I know I can exclude the ERP & rsync after install, so then lets go back to standing in front of a new hardware with a usb drive with ubuntu saerver on it
[20:43] <Guest44454> That usb drive contains my config, somewhere?
[20:45] <meena> Guest44454: usually, when creating an image, you shrink / truncate it to the most minimal size. So, a complex application might be somewhere between 500M and 9G. But 350G is… unusual.
[20:46] <Guest44454> My 350Gb was raw. Our existing ERP & data
[20:47] <minimal> Guest44454: well typically you'd have a disk image and then in the cloud-init user-data you would grow the partitions and copy data onto the machine via smb/nfs/http/etc
[20:47] <minimal> rather than bundling data into the disk image
[20:47] <Guest44454> Ah ok....
[20:48] <minimal> otherwise you'd end up with a disk image designed specifically for *one* machine which really negates the point of creating a disk image/using cloud-init in the first place
[20:49] <meena> yeah, bundling data is usually bad, it makes migrations hard
[20:50] <blackboxsw> Guest44454: ds=nocloud[;key=val;key=val] are directives that folks can use if launching KVM instances though QEMU or if they have access to set SMBIOS settings on their cloud platform, so probably not generally a bare-metal deployment approach. The live-server installer that memyselfandubunt mentioned is generally leveraging cloud-init to setup NoCloud datasource config based on configuration options chosen during install.
[20:51] <Guest44454> Just on a call, thanks guys, I have more input :)
[20:57] <Guest44454> Back
[20:58] <blackboxsw> note that live-serverinstall is also supporting automated-installs https://ubuntu.com/server/docs/install/autoinstall-reference  && https://discourse.ubuntu.com/t/automated-server-install-quickstart/16614
[20:59] <Guest44454> Ok, so I shrink my existing, working (lets say new install with all software installed) image & copy it to somewhere on my installation media. (If it is big enough or call it via http ot ftp if I recall correctly?
[20:59] <Guest44454> cloud-init will then inflate / install from that image
[21:00] <meena> Guest44454: growpart and resizefs modules is what do that
[21:00] <Guest44454> is this an instruction I configure in cloud-init setup?
[21:01] <Guest44454> I do feel quite foolish asking the questions all :)
[21:01] <blackboxsw> -> have to bail for a bit.   No foolish questions :) only foolish answers 
[21:02] <Guest4445423> I am back as new guest name, I was disconnected :P
[21:04] <meena> Guest4445423: you could also /nick a nick we can recognize you under
[21:04]  * meena has something like dyslexia and dyscalculia going on, and couldn't tell Guest4445423 and Guest44454 apart
[21:04] <ice10001> Another stupid question, can I copy this conversation as reference?
[21:06] <blackboxsw> ice10001: logs are captured by an IRC bot and published here https://irclogs.ubuntu.com/2022/04/12/%23cloud-init.html
[21:06] <blackboxsw> so you can reference historical/hysterical conversations in the future
[21:07] <ice10001> blackboxsw learning new things every day lol,
[21:15] <minimal> ice10001: what I do for bare metal (i.e. physical machine) is that as part of the disk image I prepare I create a very small FAT/EXT4 partition labelled "cidata" and I put the meta-data, network-config, user-data YAML file in that partition and enable NoCloud in /etc/cloud/cloud.cfg
[21:17] <minimal> then I use a simple Linux bootable USB stick to boot any physical machine, "dd" the disk image onto the machine's HDD/SSD, mount the cidata partition from the bootstick and edit the YAML files accordingly (i.e. config hostname, IP details, etc) before doing the 1st boot
[21:17] <ice10001> Thanks minimal, that part is starting to sound familiar :), where is that partition then? On the same USB install drive?
[21:17] <minimal> s/from the bootdisk/from the HDD or SSD/
[21:19] <minimal> I create it as part of the disk image - depending on whether you're creating for BIOS or UEFI you typically will have more than a single partition required (e.g. UEFI ESP part) so its just a case of adding another very small one with the "cidata" fs label (NoCloud scans for a "cidata" filesystem
[21:19] <ice10001> ok, got that
[21:20] <minimal> I'm typically creating only a 1MiB partition as the YAML files are no size at all
[21:22] <minimal> so the network-config file is where you set DHCP or static IP config etc
[21:22] <minimal> most of the stuff is in the user-data file
[21:23] <ice10001> (y)
[21:23] <ice10001> so, can I sum up so far:
[21:28] <ice10001> minimal: Apologies, I got lost:
[21:29] <ice10001> You said: then I use a simple Linux bootable USB stick to boot any physical machine, "dd" the disk image onto the machine's HDD/SSD, mount the cidata partition from the bootstick and edit the YAML files accordingly (i.e. config hostname, IP details, etc) before doing the 1st boot
[21:29] <ice10001> If you already booted, how are you doing first boot mentioned at the end of that statement
[21:45] <ice10001> minimal: I may have understood this now: You boot the machine with your usb drive, then dd the usb image to the hdd of the machine. So the machine will start with the 'install process" as if it was installing from the usb
[21:51] <minimal> ice10001: if you "dd" a disk image onto a machine and then boot it there's no installation involved, its just running the OS as provided by the disk image
[21:52] <minimal> the USB stick could be running any Linux distro, its just a way to be able to "dd" the image onto the disk/SSD
[21:52] <ice10001> Ok thanks
[21:52] <minimal> I've been meaning to setup a PXE-based netboot as an alternative to using a USB stick