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@IBMCN Internet: [email protected] Phone: +86-10-82451493 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From: Michael Still <[email protected]> To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> 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 <[email protected]> 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@IBMCN Internet: [email protected] 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 <[email protected]> To: [email protected] 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: [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=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0&s=SiDXOoY94EWr2-3GDE9_5U6tsqgl7OqwbFzSwJrGAzA&e= __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?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: [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=0b05NYxdutLoT3zTF5t-KEYfQwqfqEAMQk63ZLjrHvc&s=24HEDjCD0EBpKd90iVibbyuNogfp23J4kaQxD-BgHuY&e=
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
