Open Stack

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
>
> [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 <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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180418/1043bd4f/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/1043bd4f/attachment.gif>