Thanks for raising this question, really helpful to the enhancement of our driver
for the run_validation=False issue, you are right, because z/VM driver only support config drive and don't support metadata service ,we made bad assumption and took wrong action to disabled the whole ssh check, actually according to [1] , we should only disable CONF.compute_feature_enabled.metadata_service but keep both self.run_ssh and CONF.compute_feature_enabled.config_drive as True in order to make config drive test validation take effect, our CI will handle that For the tgz/iso9660 question below, this is because we got wrong info from low layer component folks back to 2012 and after discuss with some experts again, actually we can create iso9660 in the driver layer and pass down to the spawned virtual machine and during startup process, the VM itself will mount the iso file and consume it, because from linux perspective, either tgz or iso9660 doesn't matter , only need some files in order to transfer the information from openstack compute node to the spawned VM. so our action is to change the format from tgz to iso9660 and keep consistent to other drivers. For the config drive working mechanism question, according to [2] z/VM is Type 1 hypervisor while Qemu/KVM are mostly likely to be Type 2 hypervisor, there is no file system in z/VM hypervisor (I omit too much detail here) , so we can't do something like linux operation system to keep a file as qcow2 image in the host operating system, what we do is use a special file pool to store the config drive and during VM init process, we read that file from special device and attach to VM as iso9660 format then cloud-init will handle the follow up, the cloud-init handle process is identical to other platform Again, The tgz/iso9660 format is only because tgz format being wrongly thought, we already have some existing customers and a public openstack cloud [3] running on LinuxONE (system z) [4] so config drive of z/VM driver does work and we will modify our code to be consistent to community in our patch set please let us know any further question, thanks [1] https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py#L68 [2]https://en.wikipedia.org/wiki/Hypervisor [3]https://linuxone20.cloud.marist.edu/cloud/ [4]https://www.zdnet.com/article/linuxone-ibms-new-linux-mainframes/ Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: [email protected] Phone: +86-10-82451493 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From: melanie witt <[email protected]> To: [email protected] Date: 04/13/2018 03:39 AM Subject: 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tempest_blob_master_tempest_scenario_test-5Fserver-5Fbasic-5Fops.py&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=d9VEfLe0LqlPnfL0F0DwKa5iNpsRfDQKiobInGR02lc&s=0X5hrQ3zh7vwq7wJJAbox4M_4p0myAC1zehbbxYGNF8&e= __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=d9VEfLe0LqlPnfL0F0DwKa5iNpsRfDQKiobInGR02lc&s=hU-eEpSb-YMBEMckcP_GgysY7R0t33mnCEQyJ0sbECU&e=
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
