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

Fri Aug 9 05:50:24 UTC 2019

Roman, Alan
As an alternative of using ISO we can switch to usb stick image:
1. It's supported by RedFish [1]
2. It should have RW capabilities
3. We probably can convert cloud image qcow2 to raw and just perform 'dd'
to device (having nix based OS for airshipctl will be only requirement here)
4. Everyone are using usb sticks for OS deployment  since it's hard to find
CD-R to burn nowadays :)

On Fri, Aug 9, 2019 at 3:51 AM Roman Gorshunov <paye600 at gmail.com> wrote:

> Alan,
>
> The go-diskfs doesn’t seem support manipulation of existing ISO’s. README
> says
> that “Any attempt to Mkdir() or OpenFile() in write/append/create modes or
> Write()
> to the file will result in an error.” [0].
>
> Therefore, there would be a need to extract contents of existing iso, and
> rebuild it
> (go-diskfs supports El Torito cd-rom spec, which allows cd’s to be
> bootable).
>
> [0] https://github.com/diskfs/go-diskfs#read-only-filesystems
>
> Best regards,
> —
> Roman Gorshunov
>
> > On 9 Aug 2019, at 00:42, MEADOWS, ALAN <am240k at att.com> wrote:
> >
> > 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.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.
> >
> >    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 at 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=
> >
>
>
> _______________________________________________
> Airship-discuss mailing list
> Airship-discuss at lists.airshipit.org
> http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss

-- 
Kind regards
Dmitry Ukov
Principal Deployment Engineer
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.airshipit.org/pipermail/airship-discuss/attachments/20190809/5b05b331/attachment-0001.html>