Roman, The go-lang library I had been looking at that supported reading and writing iso9660 (iso) images was diskfs: https://github.com/diskfs/go-diskfs The code samples on the README will walk you through filesystem manipulation. With regard to iso9660 filesystems, this does seem to have the ability to create iso9660 filesystems (https://github.com/diskfs/go-diskfs/blob/master/filesystem/iso9660/iso9660.g...) however I have not found or found the right examples that simply demonstrate manipulating an existing ISO (e.g. dropping in a file). Certain comments (like this one https://github.com/diskfs/go-diskfs/blob/master/filesystem/iso9660/iso9660.g...) have me wondering if there are some gaps or I have simply not spent enough time with it to understand the interfaces correctly. This presumed that operators would come to the table with (LiveCD) ISOs already generated and the responsibility of `airshipctl bootstral isogen` (or perhaps a better name) would be strictly to open up the path to the ISO, write cloud-init data in the right location, and write it back, preferably as a new image on the disk so the original remains untouched. To help operators generate custom LiveCDs though that have the packages they want pre-installed, I had envisioned we would be providing a separate toolkit to help build these images (whether this is containerized, bash, python, go-lang was entirely the choice of this toolkit. This would be an alternative to operators using out of the box LiveCDs from vendors. Anyways, this was the idea behind many of my comments on that call. As I mentioned on the etherpad, while having airshipctl call out to a runtime environment with an agreed upon interface to launch an operator provided container that would do this manipulation adds a dependency on airshipctl<->containers, it may make the operation of building that LiveCD more repeatable as the container image to use would be part of your declaration. In the above, it was a separate out of band process you would follow. Alan Meadows On 8/8/19, 7:17 AM, "Roman Gorshunov" <paye600@gmail.com> wrote: Hello team, Hello Alan, Following up on an Airship-bootstrap call we have had yesterday, Alan described his alternative (lines 92-95 here https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_Airship-5Fbootstrap&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OI-s0Rr_BtNj0OcKWGZyuA&m=39e3KOJnyQM7A29deZ-dZk7USCOUThcpuXal7e2-zVM&s=EJ4k-ZQq9rUccFvreOF8yFdVt1QeKZURrJ71OdPNyAU&e=, search for "isogen uses native go-lang library") which he was talking about close to the end of the call. I remember Alan has described this approach previously on one of design calls, I did not forget about it and I love this solution. What I was thinking about yesterday, was that creating a golang module for the airshipctl would be more complicated (at least for me) than to create a container image for a proof-of-concept stage. I'm all for not having containerd dependency in release version of airshipctl. I'd like to hear your feedback on this. Alan, What was the golang library you were talking about which could open and amend ISO image contents? And another question is what are the standard ISO images (esp. LiveCD) provided by vendors which have built-in cloud-init? Recording: https://urldefense.proofpoint.com/v2/url?u=https-3A__attcorp.webex.com_attcorp_lsr.php-3FRCID-3Da05f4d1d798f40d79dfda57c9fa0e131&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OI-s0Rr_BtNj0OcKWGZyuA&m=39e3KOJnyQM7A29deZ-dZk7USCOUThcpuXal7e2-zVM&s=gOk3Ob1SfPyaSoEOgsC5DfYYDKur9gXSPJJVHEbR_VU&e= Recording password: HkYjdjq3 Recordings are stored on the server for 30 days only. Best regards, -- Roman Gorshunov _______________________________________________ Airship-discuss mailing list Airship-discuss@lists.airshipit.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit.org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OI-s0Rr_BtNj0OcKWGZyuA&m=39e3KOJnyQM7A29deZ-dZk7USCOUThcpuXal7e2-zVM&s=XEWJDL-YgGbN8ea1Y8Fvr4w9z8k6fynozH0GFPrBcKM&e=