openstack
/
nova-specs
Code Issues Proposed changes
nova-specs/specs/rocky/implemented/add-zvm-driver-rocky.rst

299 lines
9.9 KiB
ReStructuredText
Raw Blame History

..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==================
Add z/VM Support
==================
https://blueprints.launchpad.net/nova/+spec/add-zvm-driver-rocky
Add z/VM support in nova tree.
z/VM provides a highly secure and scalable enterprise cloud infrastructure
and an environment for efficiently running multiple diverse critical
applications on IBM z Systems and IBM LinuxONE with support for more
virtual servers than any other platform in a single footprint.
These z/VM virtual servers can run Linux, z/OS and more.
The detailed information can be found at http://www.vm.ibm.com/
Problem description
===================
z/VM
The z/VM driver team has met the following requirements
from the Nova core team by refer to previous virt driver integration.
* CI running and publishing results against Nova and nova-zvm driver:
Results are publicly available, as well as the configuration of the CI.
Per guidance from the Nova core team, the CI runs against all Nova change
sets but is not currently voting on patches as it is not an in-tree driver.
The `CI test logs`_ is also publicly available.
* External users beyond z/VM itself:
Companies are actively using the z/VM driver to integrate into OpenStack
clouds like SuSE; Canonical and RHEL are under discussion.
Currently `Openmainframe project`_ is the major technical community and open
project for mainframe enablement including openstack other open source
projects.
* Show commitment to the driver:
Our first supported release was Icehouse and we continue to maintain,
extend the driver with each subsequent release, following the stable branch
support model. We are committed to developing the driver following the
`OpenStack way`_, with open source code, open design/development, and an
open community. The z/VM driver fits the Nova compute driver design,
and follows the community development direction.
We also ensure that the development team is actively
participating in upstream development - attending IRC meetings, mid-cycles,
and summits.
.. _`CI test logs`: http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/
.. _`OpenStack way`: https://governance.openstack.org/reference/new-projects-requirements.html
.. _`Openmainframe project`: http://openmainframeproject.org/
Config Drive of z/VM driver
---------------------------
There are two ways to pass metadata from openstack (nova) to spawned server
now, one is `Metadata`_ and the other is `Config Drive`_.
For Now, z/VM driver only support Config Drive, which is, nova compute service
packs an ISO9660 or vfat format generated by nova community's configure drive
build, and the server mounts the file before cloud Active engine (by default
it's cloud-init); When cloud-init startup, it checks the inputed metadata and
update server's ip, hostname and other items accordingly.
The metadata service is optional feature and expected by some features and some
deployers don't use it because of security concern, z/VM driver team will add
the support of metadata service in the near future (possibily through another
nova-spec).
.. _`Metadata`: https://docs.openstack.org/nova/latest/user/metadata-service.html
.. _`Config Drive`: https://docs.openstack.org/nova/latest/user/config-drive.html
Special active engine
---------------------
Per above discussion, the cloud-init is the primary and mostly used active
engine in the cloud now. The cloud-init has `pre-requirements`_ of config
drive, but z/VM itself can't simulate a iso9660 format disk in the definition
of the virtual machine, because of that, z/VM driver team introduced a small
Active engine which was called zvmguestconfigure.
`zvmguestconfigure`_ is part of `z/VM Cloud Connector`_ which is used by nova
z/VM driver to manage z/VM. It is documented at `z/VM Image build`_ including
why the active engine is needed and where it is located, also, in addition for
user to create image, it provides a set of instructions on different
distributions.
The basic workflow will be:
* Nova boot an instance and metadata will be created through config drive
* config drive (ISO9660) send from nova compute node to spawned instance
* spawned instance already had zvmguestconfigure Active engine installed
* during boot stage, zvmguestconfigure will get the config drive and mount it
* cloud-init will look for config drive and handle the update
.. _`zvmguestconfigure`: https://github.com/mfcloud/python-zvm-sdk/blob/master/tools/share/zvmguestconfigure
.. _`z/VM cloud connector`: https://github.com/mfcloud/python-zvm-sdk/
.. _`pre-requirements`: https://github.com/number5/cloud-init/blob/3b712fcea9ca685c5cb761ea19c5126acf8ffaa1/cloudinit/sources/DataSourceConfigDrive.py#L225
.. _`z/VM Image build`: http://cloudlib4zvm.readthedocs.io/en/latest/makeimage.html#configuration-of-activation-engine-ae-in-zlinux
Neutron z/VM agent
------------------
z/VM nova driver need cooperate with neutron to add NIC. The agent is
`neutron zvm agent`_ and currently it uses ML2 plugin.
.. _`neutron zvm agent`: https://github.com/openstack/networking-zvm
Use Cases
---------
* A user should be able to deploy a glance-based image with basic networking on
a system with the z/VM hypervisor. That image may be Linux (RHEL, SLES,
Ubuntu, etc...).
Proposed change
===============
The change proposed is to submit a series of patches building out enough basic
function to support deployment of a glance-based virtual machine on z/VM.
This subset of the driver code (and associated unit tests) would support
features such as:
* Basic VM lifecycle tasks (spawn, shutdown, reboot, snapshot, etc)
* Instance status
* console output
* Flat/VLAN networking using the z/VM neutron agent
This phase of the driver is meant to get the net minimum of `mandatory` and
`choice` options from the `support matrix`_.
.. _`support matrix`: http://docs.openstack.org/developer/nova/support-matrix.html
We see this as a long-term journey. We will continue to work to bring further
functionality into the Nova tree over subsequent releases.
Some of the specific functions supported in out-of-tree driver now
that would come as part of future blueprints that are not part of this one:
* Resize
* Cold Migrate
Alternatives
------------
1) Integrate the entire driver. That would be too unwieldy to do in one
release and would require too much core reviewer time.
2) Do not integrate the driver. As there are users of the driver, and the Nova
direction is to have drivers in-tree, this is not an option.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
Deployers who wish to use the z/VM driver will need to change the
``compute_driver`` in their conf to ``zvm.zVMDriver``. The in-tree
z/VM driver will initially have a very limited set of functionality. As
noted above, they can install the nova-zvm out-of-tree driver to gain the
additional functionality while the team works over multiple releases to
integrate the driver.
For this first integration, there will be no required configuration from the
deployer beyond setting the ``compute_driver`` type. The driver will be
documented in the hypervisor support matrix (along with its capabilities
in-tree).
Developer impact
----------------
None
Upgrade impact
--------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
jichenjc
rhuang
ychuang
Other contributors:
Work Items
----------
* Add support for basic life cycle tasks (Create, Power On/Off, Delete)
* Add console output
* Increase the scope of the existing z/VM CI to include the z/VM driver
in-tree. Two jobs will need to be kicked off for each Nova change (one
for out-of-tree, one for in-tree) during this transition period.
Dependencies
============
None
Testing
=======
All code paths run through the standard Tempest tests as part of our CI. The
code will also include significant unit test. This code will come from the
out-of-tree nova-zvm driver. The CI infrastructure will also continue to
support the automated testing of the out-of-tree nova-zvm driver.
Documentation Impact
====================
As there is no ID team now, we will primary work on following documents
and other doc that related to virt driver as well:
https://docs.openstack.org/nova/latest/admin/arch.html#hypervisors
https://docs.openstack.org/nova/latest/admin/configuration/hypervisors.html
http://docs.openstack.org/developer/nova/support-matrix.html
References
==========
* nova-zvm:
* Overview: Out-of-tree Nova driver for z/VM
* Source: `<https://git.openstack.org/cgit/openstack/nova-zvm-virt-driver/>`_
* Bugs: `<https://bugs.launchpad.net/nova-zvm-virt-driver/>`_
* neutron-zvm-agent:
* Overview: Open source z/VM neutron agent
* Source: `<https://git.openstack.org/cgit/openstack/networking-zvm/>`_
* Bugs: `<https://bugs.launchpad.net/networking-zvm/>`_
* ceilometer-zvm:
* Overview: Ceilometer collector for the z/VM platform. Captures I/O,
CPU and memory statistics.
* Source: `<https://git.openstack.org/cgit/openstack/ceilometer-zvm/>`_
* Bugs: `<https://bugs.launchpad.net/ceilometer-zvm/>`_
History
=======
z/VM used to submit patches and has some discussions with nova community back
to 2013/2014 time frame. At that time we are lack of CI so we followed
guidelines in creating our CI and do more contributions to community.
And we had more effort in CI test and more cooperation with wider community
like Open mainframe project `<https://www.openmainframeproject.org/>`_
talked above, we want to continue our effort to make z/VM accepted
as in-tree plugin.
.. list-table:: Revisions
:header-rows: 1
* - Release Name
- Description
* - Queens
- Introduced, approved, implementation started
* - Rocky
- Reproposed
View Git Blame Copy Permalink