Open Stack

The more I think about it, the more I dislike how the proposed driver also
"lies" about it using iso9660. That's definitely wrong:

        if CONF.config_drive_format in ['iso9660']:
            # cloud-init only support iso9660 and vfat, but in z/VM
            # implementation, can't link a disk to VM as iso9660 before it's
            # boot ,so create a tgz file then send to the VM deployed, and
            # during startup process, the tgz file will be extracted and
            # mounted as iso9660 format then cloud-init is able to consume
it
            self._make_tgz(path)
        else:
            raise exception.ConfigDriveUnknownFormat(
                format=CONF.config_drive_format)

Michael

On Thu, Apr 12, 2018 at 9:28 AM, Dan Smith <dms at danplanet.com> wrote:

> > https://review.openstack.org/#/c/527658 is a z/VM patch which
> > introduces their support for config drive. They do this by attaching a
> > tarball to the instance, having pretended in the nova code that it is
> > an iso9660. This worries me.
> >
> > In the past we've been concerned about adding new filesystem formats
> > for config drives, and the long term support implications of that --
> > the filesystem formats for config drive that we use today were
> > carefully selected as being universally supported by our guest
> > operating systems.
> >
> > The previous example we've had of these issues is the parallels
> > driver, which had similar "my hypervisor doesn't support these
> > filesystem format" concerns. We worked around those concerns IIRC, and
> > certainly virt.configdrive still only supports iso9660 and vfat.
>
> Yeah, IIRC, the difference with the parallels driver was that it ends up
> mounted in the container automagically for the guest by the..uh..man
> behind the curtain. However, z/VM being much more VM-y I imagine that
> the guest is just expected to grab that blob and do something with it to
> extract it on local disk at runtime or something. That concerns me too.
>
> In the past I've likened adding filesystem (or format, in this case)
> options to configdrive as a guest ABI change. I think the stability of
> what we present to guests is second only to our external API in terms of
> importance. I know z/VM is "weird" or "different", but I wouldn't want a
> more conventional hypervisor exposing the configdrive as a tarball, so I
> don't really think it's a precedent we should set. Both vfat and iso9660
> are easily supportable by most everything on the planet so I don't think
> it's an unreasonable bar.
>
> --Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180412/01d0a478/attachment.html>