Open Stack

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 at IBMCN   Internet: jichenjc at cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:	melanie witt <melwittt at gmail.com>
To:	openstack-dev at lists.openstack.org
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: OpenStack-dev-request at lists.openstack.org?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=




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180413/a62e7bc9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180413/a62e7bc9/attachment.gif>