=== FergusL6 is now known as FergusL
=== arif-ali- is now known as arif-ali
[12:12] <minimal> Hi. For the network device hotplug stuff added recently any plans for init.d scripts in addition to the systemd scripts already there? Starting to look at how to enable this for a non-systemd OS
[16:01] <falcojr> minimal: no, at this time there are no plans for adding non-systemd scripts
[16:03] <minimal> falcojr: ok. I'm working on equivalent init.d scripts for Alpine currently. I've rewritten hook-hotplug locally so that it does not depend on Bash. As I'm not familiar with Systemd's handling of FIFOs I'm trying to work out what the init.d equivalent of cloud-init-hotplugd.socket would be
[16:08] <falcojr> I'll be no help with it comes to init.d, but contributions are always welcome
[16:12] <minimal> yet I'll contribute whatever I come up with, for now as I don't quite understand what the systemd setup is doing its hard to write an init.d equivalent
[16:12] <minimal> s/yet/yeah/
[19:20] <rharper> minimal: w.r.t the fifo socket, you can use mkfifo ; I may have had an initial implementation with mkfifo before using systemd's FIFO,  the goal is to provide a writable FIFO for the ACPI called hotplug hook script so it can stash uevent parameters (nic details) in a FIFO;  the daemon blocks on reading from the fifo and should work whether systemd or mkfifo created the file 
[19:25] <minimal> rharper: yeah wasn't too sure if "mknod p" is needed in addition to mkfifo
[19:29] <minimal> so write init.d script "cloud-init-create-fifo" to do mknod/mkfifo and have existing "cloud-init" script (or "cloud-final"?) define a "need cloud-init-create-fifo"
[19:53] <rharper> minimal: the cloud-hotplugd runs as a service, and it 1) creates the fifo at /run/cloud-init/hotplug (or something like that)  2) spawns the daemon service which will open and block reading from the fifo ;   so you'll need an init script to do (1) and (2) in the right order  potentially you could combine (1) and (2) like the systemd unit does; 
[19:59] <minimal> rharper: yeah don't see the point of 2 init.d scripts, will do it in single one. I'll try and find some time in the next week to try it out
[20:06] <esv> is this a group for cloud-init devs or dumb users like me too?
[20:06] <minimal> both :-)
[20:06] <rharper> esv: for anyone with questions 
[20:07] <rharper> where ever you're at 
[20:08] <esv> I imagine cloud-init runs in at least 2 phases, machine provisioning/deployment and regular reboots. 
[20:08] <esv> is that correct?
[20:08] <rharper> it runs every boot;, it has 4 stages during each boot 
[20:08] <esv> I am thinking virtual machines in the public cloud 
[20:08] <rharper> https://cloudinit.readthedocs.io/en/latest/topics/boot.html 
[20:09] <esv> ohhhh
[20:09] <rharper> yes, works the same on real machines and virtual 
[20:09] <rharper> w.r.t stages and boots (first boot or subsequent boots after initializing) 
[20:10] <esv> cool, guess I'll be away reading for a bit
[20:10] <rharper> if you don't find an answer, ask in here (and we can add/update docs to clarify things if needed) 
[20:11] <minimal> rharper: BTW in case you're interested, I've been working on a script for building physical/VM/cloud disk images of Alpine with cloud-init enabled. The physical images use a partition for the YAML config.
[20:11] <minimal> https://github.com/dermotbradley/create-alpine-disk-image
[20:14] <rharper> minimal: nice!  
[20:14] <minimal> its still a WIP - have only extensively tested QEMU and VirtualBox and physical machines. Need to spend some time testing the various Cloud Providers
[20:43] <menace> hi, is there a standard way for cloud-init to set for network boot images like fdi-bootable.iso the IP/Range and Gateway?
[21:06] <rharper> menace: I'm not familiar with fdi-bootable.iso ; does it have cloud-init in the OS image that runs?  
[21:06] <rharper> https://github.com/theforeman/foreman-discovery-image   <-- this? 
[21:06] <menace> yes, that
[21:07] <rharper> without digging, I can't tell what's included in the OS image it boots, I don't expect that cloud-init is included in the fdi image ,,, do you know if it is ? 
[21:07] <menace> i just cloned the repo, i do not see it. i have to have a look tomorrow at the actual disk image
[21:08] <menace> but that's actually a good idea, thank you
[21:08] <rharper> https://github.com/theforeman/foreman-discovery-image/blob/master/20-packages.ks   looks like what packages iti install s
[21:10] <menace> actually, the problem is, that we have a script which does some modifications and i somewhat thought, that there's a mode for cloud-init to modify the image from outside into the inside.. because our script is not that stable...
[21:14] <rharper> I've seen cloud-init used in two modes, the most typical is that an bootable image which needs to be customized *during boot*, cloud-init will read config from different places (local or remote) and apply the config (network, run scripts, install packages, etc) ...  the second mode is creating a customized template image by supplying cloud-init configuration, boot it once and allow cloud-init to configure it, then remove some 
[21:14] <rharper> artifacts such that the modified image is a custom template image; 
=== mamercad9 is now known as mamercad