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 > > [image: 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
