[Airship-discuss] [sig][airship-bootstrap] airshipctl golang module vs. airshipctl interacting with a docker container
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.
On 8/8/19, 7:17 AM, "Roman Gorshunov" <paye600 at gmail.com> wrote:
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 password: HkYjdjq3
Recordings are stored on the server for 30 days only.
Airship-discuss mailing list
Airship-discuss at lists.airshipit.org
More information about the Airship-discuss