Open Stack

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://github.com/number5/cloud-init/blob/master/cloudinit/sources/DataSourceConfigDrive.py#L225

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://github.com/openstack/nova/blob/888cd51/nova/virt/hyperv/vmops.py#L661
[1] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/ironic/driver.py#L974
[2] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/libvirt/driver.py#L3595
[3] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/powervm/media.py#L120
[4] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/vmwareapi/vmops.py#L854
[5] 
https://github.com/openstack/nova/blob/888cd51/nova/virt/xenapi/vm_utils.py#L1151