<div dir="ltr">Roman, Alan<div>As an alternative of using ISO we can switch to usb stick image: </div><div>1. It's supported by RedFish [1]</div><div>2. It should have RW capabilities</div><div>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)</div><div>4. Everyone are using usb sticks for OS deployment since it's hard to find CD-R to burn nowadays :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 9, 2019 at 3:51 AM Roman Gorshunov <<a href="mailto:paye600@gmail.com">paye600@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Alan,<br>
<br>
The go-diskfs doesn’t seem support manipulation of existing ISO’s. README says<br>
that “Any attempt to Mkdir() or OpenFile() in write/append/create modes or Write()<br>
to the file will result in an error.” [0].<br>
<br>
Therefore, there would be a need to extract contents of existing iso, and rebuild it<br>
(go-diskfs supports El Torito cd-rom spec, which allows cd’s to be bootable).<br>
<br>
[0] <a href="https://github.com/diskfs/go-diskfs#read-only-filesystems" rel="noreferrer" target="_blank">https://github.com/diskfs/go-diskfs#read-only-filesystems</a><br>
<br>
Best regards,<br>
—<br>
Roman Gorshunov<br>
<br>
> On 9 Aug 2019, at 00:42, MEADOWS, ALAN <<a href="mailto:am240k@att.com" target="_blank">am240k@att.com</a>> wrote:<br>
> <br>
> Roman,<br>
> <br>
> The go-lang library I had been looking at that supported reading and writing iso9660 (iso) images was diskfs:<br>
> <br>
> <a href="https://github.com/diskfs/go-diskfs" rel="noreferrer" target="_blank">https://github.com/diskfs/go-diskfs</a><br>
> <br>
> 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 (<a href="https://github.com/diskfs/go-diskfs/blob/master/filesystem/iso9660/iso9660.go#L49-L64" rel="noreferrer" target="_blank">https://github.com/diskfs/go-diskfs/blob/master/filesystem/iso9660/iso9660.go#L49-L64</a>) 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 <a href="https://github.com/diskfs/go-diskfs/blob/master/filesystem/iso9660/iso9660.go#L49-L64" rel="noreferrer" target="_blank">https://github.com/diskfs/go-diskfs/blob/master/filesystem/iso9660/iso9660.go#L49-L64</a>) have me wondering if there are some gaps or I have simply not spent enough time with it to understand the interfaces correctly.<br>
> <br>
> 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.<br>
> <br>
> Anyways, this was the idea behind many of my comments on that call.<br>
> <br>
> 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.<br>
> <br>
> Alan Meadows<br>
> <br>
> On 8/8/19, 7:17 AM, "Roman Gorshunov" <<a href="mailto:paye600@gmail.com" target="_blank">paye600@gmail.com</a>> wrote:<br>
> <br>
> Hello team,<br>
> Hello Alan,<br>
> <br>
> Following up on an Airship-bootstrap call we have had yesterday, Alan<br>
> described his alternative (lines 92-95 here<br>
> <a href="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=" rel="noreferrer" target="_blank">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=</a>, search for "isogen<br>
> uses native go-lang library") which he was talking about close to the<br>
> end of the call.<br>
> <br>
> I remember Alan has described this approach previously on one of<br>
> design calls, I did not forget about it and I love this solution. What<br>
> I was thinking about yesterday, was that creating a golang module for<br>
> the airshipctl would be more complicated (at least for me) than to<br>
> create a container image for a proof-of-concept stage. I'm all for not<br>
> having containerd dependency in release version of airshipctl.<br>
> I'd like to hear your feedback on this.<br>
> <br>
> Alan,<br>
> What was the golang library you were talking about which could open<br>
> and amend ISO image contents?<br>
> <br>
> And another question is what are the standard ISO images (esp. LiveCD)<br>
> provided by vendors which have built-in cloud-init?<br>
> <br>
> Recording: <a href="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=" rel="noreferrer" target="_blank">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=</a><br>
> Recording password: HkYjdjq3<br>
> Recordings are stored on the server for 30 days only.<br>
> <br>
> Best regards,<br>
> --<br>
> Roman Gorshunov<br>
> <br>
> _______________________________________________<br>
> Airship-discuss mailing list<br>
> <a href="mailto:Airship-discuss@lists.airshipit.org" target="_blank">Airship-discuss@lists.airshipit.org</a><br>
> <a href="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=" rel="noreferrer" target="_blank">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=</a><br>
> <br>
<br>
<br>
_______________________________________________<br>
Airship-discuss mailing list<br>
<a href="mailto:Airship-discuss@lists.airshipit.org" target="_blank">Airship-discuss@lists.airshipit.org</a><br>
<a href="http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss" rel="noreferrer" target="_blank">http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Kind regards<div>Dmitry Ukov</div><div>Principal Deployment Engineer</div><div><div>Mirantis, Inc.</div></div><div><br></div></div></div></div>