<html><body><p><font size="2">Thanks for raising this question, really helpful to the enhancement of our driver</font><br><br><font size="2">for the </font><tt><font size="2">run_validation=False</font></tt><font size="2"> issue, you are right, because z/VM driver only support config drive and don't support metadata service ,we made bad assumption</font><br><font size="2">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</font><br><font size="2">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 </font><br><br><font size="2">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</font><br><font size="2">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</font><br><font size="2">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.</font><br><font size="2">so our action is to change the format from tgz to iso9660 and keep consistent to other drivers.</font><br><br><font size="2">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 </font><br><font size="2">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 </font><br><font size="2">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 </font><br><font size="2">the follow up, the cloud-init handle process is identical to other platform</font><br><br><font size="2">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]</font><br><font size="2">so config drive of z/VM driver does work and we will modify our code to be consistent to community in our patch set</font><br><br><font size="2">please let us know any further question, thanks</font><br><br><font size="2">[1]</font><a href="https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py#L68"><font size="2">https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py#L68</font></a><br><font size="2">[2]</font><a href="https://en.wikipedia.org/wiki/Hypervisor"><font size="2">https://en.wikipedia.org/wiki/Hypervisor</font></a><br><font size="2">[3]</font><a href="https://linuxone20.cloud.marist.edu/cloud/"><font size="2">https://linuxone20.cloud.marist.edu/cloud/</font></a><br><font size="2">[4]</font><a href="https://www.zdnet.com/article/linuxone-ibms-new-linux-mainframes/"><font size="2">https://www.zdnet.com/article/linuxone-ibms-new-linux-mainframes/</font></a><br><br><font size="2">Best Regards! <br><br>Kevin (Chen) Ji 纪 晨<br><br>Engineer, zVM Development, CSTL<br>Notes: Chen CH Ji/China/IBM@IBMCN Internet: jichenjc@cn.ibm.com<br>Phone: +86-10-82451493<br>Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC </font><br><br><img width="16" height="16" src="cid:1__=8FBB08FDDFA7CF328f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for melanie witt ---04/13/2018 03:39:44 AM---On Thu, 12 Apr 2018 09:31:45 +1000, Michael Still wrote: > T"><font size="2" color="#424282">melanie witt ---04/13/2018 03:39:44 AM---On Thu, 12 Apr 2018 09:31:45 +1000, Michael Still wrote: > The more I think about it, the more I dis</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">melanie witt <melwittt@gmail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">openstack-dev@lists.openstack.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">04/13/2018 03:39 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [openstack-dev] [Nova] z/VM introducing a new config drive format</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">On Thu, 12 Apr 2018 09:31:45 +1000, Michael Still wrote:<br>> The more I think about it, the more I dislike how the proposed driver <br>> also "lies" about it using iso9660. That's definitely wrong:<br>> <br>> if CONF.config_drive_format in ['iso9660']:<br>> # cloud-init only support iso9660 and vfat, but in z/VM<br>> # implementation, can't link a disk to VM as iso9660 before <br>> it's<br>> # boot ,so create a tgz file then send to the VM deployed, and<br>> # during startup process, the tgz file will be extracted and<br>> # mounted as iso9660 format then cloud-init is able to <br>> consume it<br>> self._make_tgz(path)<br>> else:<br>> raise exception.ConfigDriveUnknownFormat(<br>> format=CONF.config_drive_format)<br><br>I've asked for more information on the review about how this works -- is <br>it the z/VM library that extracts the tarball and mounts it as iso9660 <br>before the guest boots or is it expected that the guest is running some <br>special software that will do that before cloud-init runs, or what?<br><br>I also noticed that the z/VM CI has disabled ssh validation of guests by <br>setting '[validation]run_validation=False' in tempest.conf [0]. This <br>means we're unable to see the running guest successfully consume the <br>config drive using this approach. This is the tempest test that verifies <br>functionality when run_validation=True [1].<br><br>I think we need to understand more about how this config drive approach <br>is supposed to work and be able to see running instances successfully <br>start up using it in the CI runs.<br><br>-melanie<br><br>[0] <br></font></tt><tt><font size="2"><a href="http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-16244/logs/tempest_conf">http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-16244/logs/tempest_conf</a></font></tt><tt><font size="2"><br>[1] <br></font></tt><tt><font size="2"><a href="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=">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=</a></font></tt><tt><font size="2"><br><br><br><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></font></tt><tt><font size="2"><a href="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=">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=</a></font></tt><tt><font size="2"><br><br></font></tt><br><br><BR>
</body></html>