Open Stack

For the question on AE documentation, it's open source in [1] and the
documentation for how to build and use is [2]
once our code is upstream, there are a set of documentation change which
will cover this image build process by
adding some links to there [3]

You are right, we need image to have our Active Engine, I think different
arch and platform might have their unique
requirements and our solution our Active Engine is very like to cloud-init
so no harm to add it from user's perspective
I think later we can upload image to some place so anyone is able to
consume it as test image if they like
because different arch's image (e.g x86 and s390x) can't be shared anyway.

For the config drive format you mentioned, actually, as previous
explanation and discussion witho Michael and Dan,
We found the iso9660 can be used (previously we made a bad assumption) and
we already changed the patch in [4],
so it's exactly same to other virt drivers you mentioned , we don't need
special format and iso9660 works perfect for our driver

It make sense to me we are temply moved out from runway, I suppose we can
adjust the CI to enable the run_ssh = true
with config drive functionalities very soon and we will apply for review
after that with the test result requested in our CI log.

Thanks

[1]
https://github.com/mfcloud/python-zvm-sdk/blob/master/tools/share/zvmguestconfigure
[2]
http://cloudlib4zvm.readthedocs.io/en/latest/makeimage.html#configuration-of-activation-engine-ae-in-zlinux
[3] https://review.openstack.org/#/q/status:open+project:openstack/nova
+branch:master+topic:bp/add-zvm-driver-rocky
[4]  https://review.openstack.org/#/c/527658/33/nova/virt/zvm/utils.py
line 104

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/17/2018 09:21 AM
Subject:	Re: [openstack-dev] [Nova] z/VM introducing a new config
            driveformat



On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote:
>  >>>The "iso file" will not be inside the guest, but rather passed to
> the guest as a block device, right?
> Cloud init expects to find a config drive with following requirements
> [1], in order to make cloud init able to consume config drive , we
> should be able to prepare it,
> in some hypervisor, you can define something like following to the VM
> then VM startup is able to consume it
> <source file="/var/log/cloud/new/abc.iso"/>
> but for z/VM case it allows disk to be created during VM create (define
> )stage but no disk format set, it's the operating system's
> responsibility to define the purpose of the
> disk, so what we do is
> 1) first when we build image ,we create a small AE like cloud-init but
> only purpose is to get files from z/VM internal pipe and handle config
> drive case

What does AE stand for? So, this means in order to use the z/VM driver,
users must have special images that will ensure the config drive will be
readable by cloud-init. They can't use standard cloud images.

> 2) During spawn we create config drive in nova-compute side then send
> the file to z/VM through z/VM internal pipe (omit detail here)
> 3) During startup of the virtual machine, the small AE is able to mount
> the file as loop device and then in turn cloud-init is able to handle it
>
> because this is our special case, we don't want to upload to cloud-init
> community because of uniqueness and as far as we can tell, no hook in
> cloud-init mechanism allowed as well
> to let us 'mount -o loop' ; also, from openstack point of view except
> this small AE (which is documented well) no special thing and
> inconsistent to other drivers
>
> [1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_number5_cloud-2Dinit_blob_master_cloudinit_sources_DataSourceConfigDrive.py-23L225&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=3410axnNZ_62U3HOh6i7yivyc7HyTcqwx2xuKRDEeac&e=


Where is the AE documented? How do users obtain it? What tools are they
supposed to use to build images to use with the z/VM driver?

That aside, from what I can see, the z/VM driver behaves unlike any
other in-tree driver [0-5] in how it handles config drive. Drivers are
expected to create the config drive and present it to the guest in
iso9660 or vfat format without requirement of a custom image and the
existing drivers are doing that.

IMHO, if the z/VM driver can't be fixed to provide proper config drive
support, we won't be able to approve the implementation patches. I would
like to hear other opinions about it.

I propose that we remove the z/VM driver blueprint from the runway at
this time and place it back into the queue while work on the driver
continues. At a minimum, we need to see z/VM CI running with
[validation]run_validation = True in tempest.conf before we add the z/VM
driver blueprint back into a runway in the future.

Cheers,
-melanie

[0]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_888cd51_nova_virt_hyperv_vmops.py-23L661&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=7PXdcMLIrzcekkl0V3N1vML09CGgvali0Q4v-M_vrzk&e=

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_888cd51_nova_virt_ironic_driver.py-23L974&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=X1KzmZQEfiHW1O6N1j5vBJkERjrV0dDrZlkT3LjE5aY&e=

[2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_888cd51_nova_virt_libvirt_driver.py-23L3595&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=a5XhSWf7Ws5h_OuiUc_LpMVtM4ud3GoexVM1NKpBwfM&e=

[3]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_888cd51_nova_virt_powervm_media.py-23L120&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=w7kq1DhO7qw57H0ZX0uxkj1tFvLCeYOHU9QVUTmBehU&e=

[4]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_888cd51_nova_virt_vmwareapi_vmops.py-23L854&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=_G6MIr7OqLH48t8b8JGMVhg6bgCPg8bgHbPez9ohbG0&e=

[5]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_888cd51_nova_virt_xenapi_vm-5Futils.py-23L1151&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=LZK-0hqXfMqBaLHUHMA4kjE-mReBuP1vw9pYGPoqAxU&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=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=SiDXOoY94EWr2-3GDE9_5U6tsqgl7OqwbFzSwJrGAzA&e=




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180417/578e08f3/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/20180417/578e08f3/attachment.gif>