Re: [openstack-dev] [Nova] z/VM introducing a new config drive format

[melanie witt]

On Thu, 12 Apr 2018 09:31:45 +1000, Michael Still wrote:
The more I think about it, the more I dislike how the proposed driver 
also "lies" about it using iso9660. That's definitely wrong:


         if CONF.config_drive_format in ['iso9660']:
             # cloud-init only support iso9660 and vfat, but in z/VM
             # implementation, can't link a disk to VM as iso9660 before 
it's

             # boot ,so create a tgz file then send to the VM deployed, and
             # during startup process, the tgz file will be extracted and
             # mounted as iso9660 format then cloud-init is able to 
consume it

             self._make_tgz(path)
         else:
             raise exception.ConfigDriveUnknownFormat(
                 format=CONF.config_drive_format)


I've asked for more information on the review about how this works -- is 
it the z/VM library that extracts the tarball and mounts it as iso9660 
before the guest boots or is it expected that the guest is running some 
special software that will do that before cloud-init runs, or what?


I also noticed that the z/VM CI has disabled ssh validation of guests by 
setting '[validation]run_validation=False' in tempest.conf [0]. This 
means we're unable to see the running guest successfully consume the 
config drive using this approach. This is the tempest test that verifies 
functionality when run_validation=True [1].


I think we need to understand more about how this config drive approach 
is supposed to work and be able to see running instances successfully 
start up using it in the CI runs.


-melanie

[0] 
http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-16244/logs/tempest_conf
[1] 
https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config drive format

[Michael Still]

The more I think about it, the more I dislike how the proposed driver also
"lies" about it using iso9660. That's definitely wrong:

if CONF.config_drive_format in ['iso9660']:
# cloud-init only support iso9660 and vfat, but in z/VM
# implementation, can't link a disk to VM as iso9660 before it's
# boot ,so create a tgz file then send to the VM deployed, and
# during startup process, the tgz file will be extracted and
# mounted as iso9660 format then cloud-init is able to consume
it
self._make_tgz(path)
else:
raise exception.ConfigDriveUnknownFormat(
format=CONF.config_drive_format)

Michael

On Thu, Apr 12, 2018 at 9:28 AM, Dan Smith  wrote:

> > https://review.openstack.org/#/c/527658 is a z/VM patch which
> > introduces their support for config drive. They do this by attaching a
> > tarball to the instance, having pretended in the nova code that it is
> > an iso9660. This worries me.
> >
> > In the past we've been concerned about adding new filesystem formats
> > for config drives, and the long term support implications of that --
> > the filesystem formats for config drive that we use today were
> > carefully selected as being universally supported by our guest
> > operating systems.
> >
> > The previous example we've had of these issues is the parallels
> > driver, which had similar "my hypervisor doesn't support these
> > filesystem format" concerns. We worked around those concerns IIRC, and
> > certainly virt.configdrive still only supports iso9660 and vfat.
>
> Yeah, IIRC, the difference with the parallels driver was that it ends up
> mounted in the container automagically for the guest by the..uh..man
> behind the curtain. However, z/VM being much more VM-y I imagine that
> the guest is just expected to grab that blob and do something with it to
> extract it on local disk at runtime or something. That concerns me too.
>
> In the past I've likened adding filesystem (or format, in this case)
> options to configdrive as a guest ABI change. I think the stability of
> what we present to guests is second only to our external API in terms of
> importance. I know z/VM is "weird" or "different", but I wouldn't want a
> more conventional hypervisor exposing the configdrive as a tarball, so I
> don't really think it's a precedent we should set. Both vfat and iso9660
> are easily supportable by most everything on the planet so I don't think
> it's an unreasonable bar.
>
> --Dan
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config drive format

[Dan Smith]

> https://review.openstack.org/#/c/527658 is a z/VM patch which
> introduces their support for config drive. They do this by attaching a
> tarball to the instance, having pretended in the nova code that it is
> an iso9660. This worries me.
>
> In the past we've been concerned about adding new filesystem formats
> for config drives, and the long term support implications of that --
> the filesystem formats for config drive that we use today were
> carefully selected as being universally supported by our guest
> operating systems.
>
> The previous example we've had of these issues is the parallels
> driver, which had similar "my hypervisor doesn't support these
> filesystem format" concerns. We worked around those concerns IIRC, and
> certainly virt.configdrive still only supports iso9660 and vfat.

Yeah, IIRC, the difference with the parallels driver was that it ends up
mounted in the container automagically for the guest by the..uh..man
behind the curtain. However, z/VM being much more VM-y I imagine that
the guest is just expected to grab that blob and do something with it to
extract it on local disk at runtime or something. That concerns me too.

In the past I've likened adding filesystem (or format, in this case)
options to configdrive as a guest ABI change. I think the stability of
what we present to guests is second only to our external API in terms of
importance. I know z/VM is "weird" or "different", but I wouldn't want a
more conventional hypervisor exposing the configdrive as a tarball, so I
don't really think it's a precedent we should set. Both vfat and iso9660
are easily supportable by most everything on the planet so I don't think
it's an unreasonable bar.

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] z/VM introducing a new config drive format

[Michael Still]

Heya,

https://review.openstack.org/#/c/527658 is a z/VM patch which introduces
their support for config drive. They do this by attaching a tarball to the
instance, having pretended in the nova code that it is an iso9660. This
worries me.

In the past we've been concerned about adding new filesystem formats for
config drives, and the long term support implications of that -- the
filesystem formats for config drive that we use today were carefully
selected as being universally supported by our guest operating systems.

The previous example we've had of these issues is the parallels driver,
which had similar "my hypervisor doesn't support these filesystem format"
concerns. We worked around those concerns IIRC, and certainly
virt.configdrive still only supports iso9660 and vfat.

Discuss.

Michael
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev