Open Stack

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