Re: [openstack-dev] [Nova] z/VM introducing a new config drive format
On Thu, 12 Apr 2018 09:31:45 +1000, Michael Still wrote: 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) I've asked for more information on the review about how this works -- is it the z/VM library that extracts the tarball and mounts it as iso9660 before the guest boots or is it expected that the guest is running some special software that will do that before cloud-init runs, or what? I also noticed that the z/VM CI has disabled ssh validation of guests by setting '[validation]run_validation=False' in tempest.conf [0]. This means we're unable to see the running guest successfully consume the config drive using this approach. This is the tempest test that verifies functionality when run_validation=True [1]. I think we need to understand more about how this config drive approach is supposed to work and be able to see running instances successfully start up using it in the CI runs. -melanie [0] http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-16244/logs/tempest_conf [1] https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] z/VM introducing a new config drive format
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 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 > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] z/VM introducing a new config drive format
> 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] z/VM introducing a new config drive format
Heya, 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. Discuss. Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
