[openstack-dev] [Nova] z/VM introducing a new config driveformat
Chen CH Ji
jichenjc at cn.ibm.com
Wed Apr 18 09:44:30 UTC 2018
Thanks for the concern and fully under it , the major reason is cloud-init
doesn't have a hook or plugin before it start to read config drive (ISO
disk)
z/VM is an old hypervisor and no way to do something like libvirt to define
a ISO format disk in xml definition, instead, it can define disks in the
defintion
of virtual machine and let VM to decide its format.
so we need a way to tell cloud-init where to find ISO file before
cloud-init start but without AE, we can't handle that...some update on the
spec here
for further information https://review.openstack.org/#/c/562154/
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: Michael Still <mikal at stillhq.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: 04/18/2018 05:08 PM
Subject: Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat
I'm confused about the design of AE to be honest. Is there a good reason
that this functionality couldn't be provided by cloud-init? I think there's
a lot of cost in deviating from the industry standard, so the reasons to do
so have to be really solid.
I'm also a bit confused by what seems to be support for streaming
configuration. Is there any documentation on the design of AE anywhere?
Thanks,
Michael
On Tue, Apr 17, 2018 at 6:58 PM, Chen CH Ji <jichenjc at cn.ibm.com> wrote:
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
Inactive hide details for melanie witt ---04/17/2018 09:21:03 AM---On
Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote: > >>>melanie witt
---04/17/2018 09:21:03 AM---On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch
Ji wrote: > >>>The "iso file" will not be inside the gu
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=
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
__________________________________________________________________________
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=0b05NYxdutLoT3zTF5t-KEYfQwqfqEAMQk63ZLjrHvc&s=24HEDjCD0EBpKd90iVibbyuNogfp23J4kaQxD-BgHuY&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180418/48c2b93d/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/20180418/48c2b93d/attachment.gif>
More information about the OpenStack-dev
mailing list
