[Airship-discuss] [sig][airship-bootstrap] airshipctl golang module vs. airshipctl interacting with a docker container

MEADOWS, ALAN am240k at att.com
Thu Aug 8 22:42:15 UTC 2019


The go-lang library I had been looking at that supported reading and writing iso9660 (iso) images was 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.go#L49-L64) 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.go#L49-L64) 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 at 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.
    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 at lists.airshipit.org

More information about the Airship-discuss mailing list