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
