<div dir="ltr">The more I think about it, the more I dislike how the proposed driver also "lies" about it using iso9660. That's definitely wrong:<div><br></div><div><div>        if CONF.config_drive_format in ['iso9660']:</div><div>            # cloud-init only support iso9660 and vfat, but in z/VM</div><div>            # implementation, can't link a disk to VM as iso9660 before it's</div><div>            # boot ,so create a tgz file then send to the VM deployed, and</div><div>            # during startup process, the tgz file will be extracted and</div><div>            # mounted as iso9660 format then cloud-init is able to consume it</div><div>            self._make_tgz(path)</div><div>        else:</div><div>            raise exception.ConfigDriveUnknownFormat(</div><div>                format=CONF.config_drive_format)</div><div><br></div><div>Michael</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 12, 2018 at 9:28 AM, Dan Smith <span dir="ltr"><<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> <a href="https://review.openstack.org/#/c/527658" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/527658</a> is a z/VM patch which<br>
> introduces their support for config drive. They do this by attaching a<br>
> tarball to the instance, having pretended in the nova code that it is<br>
> an iso9660. This worries me.<br>
><br>
> In the past we've been concerned about adding new filesystem formats<br>
> for config drives, and the long term support implications of that --<br>
> the filesystem formats for config drive that we use today were<br>
> carefully selected as being universally supported by our guest<br>
> operating systems.<br>
><br>
> The previous example we've had of these issues is the parallels<br>
> driver, which had similar "my hypervisor doesn't support these<br>
> filesystem format" concerns. We worked around those concerns IIRC, and<br>
> certainly virt.configdrive still only supports iso9660 and vfat.<br>
<br>
</span>Yeah, IIRC, the difference with the parallels driver was that it ends up<br>
mounted in the container automagically for the guest by the..uh..man<br>
behind the curtain. However, z/VM being much more VM-y I imagine that<br>
the guest is just expected to grab that blob and do something with it to<br>
extract it on local disk at runtime or something. That concerns me too.<br>
<br>
In the past I've likened adding filesystem (or format, in this case)<br>
options to configdrive as a guest ABI change. I think the stability of<br>
what we present to guests is second only to our external API in terms of<br>
importance. I know z/VM is "weird" or "different", but I wouldn't want a<br>
more conventional hypervisor exposing the configdrive as a tarball, so I<br>
don't really think it's a precedent we should set. Both vfat and iso9660<br>
are easily supportable by most everything on the planet so I don't think<br>
it's an unreasonable bar.<br>
<span class="HOEnZb"><font color="#888888"><br>
--Dan<br>
</font></span></blockquote></div><br></div>