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
             raise exception.ConfigDriveUnknownFormat(

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.


[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

Reply via email to