nova-powervm 9.0.0

Data Model Impact

• The evacuate API is supported as part of the PowerVM driver. It optionally allows for the NVRAM data to be stored to a Swift database. However this does not impact the data model itself. It simply provides a location to optionally store the VM’s NVRAM metadata in the event of a rebuild, evacuate, shelve, migration or resize.

REST API Impact

No REST API impacts.

Security Impact

No known security impacts.

Notifications Impact

No new notifications. The driver does expect that the Neutron agent will return an event when the VIF plug has occurred, assuming that Neutron is the network service.

Other End User Impact

The administrator may notice new logging messages in the nova compute logs.

Performance Impact

The driver has a similar deployment speed and agility to other hypervisors. It has been tested with up to 10 concurrent deploys with several hundred VMs on a given server.

Most operations are comparable in speed. Deployment, attach/detach volumes, lifecycle, etc… are quick.

Due to the nature of the project, any performance impacts are limited to the Compute Driver. The API processes for instance are not impacted.

Other Deployer Impact

The cloud administrator will need to refer to documentation on how to configure OpenStack for use with a PowerVM hypervisor.

A ‘powervm’ configuration group is used to contain all the PowerVM specific configuration settings. Existing configuration file attributes will be reused as much as possible (e.g. vif_plugging_timeout). This reduces the number of PowerVM specific items that will be needed.

It is the goal of the project to only require minimal additional attributes. The deployer may specify additional attributes to fit their configuration.

Developer Impact

The code for this driver is currently contained within a powervm project. The driver is within the /nova/virt/powervm_ext/ package and extends the nova.virt.driver.ComputeDriver class.

The code interacts with PowerVM through the pypowervm library. This python binding is a wrapper to the PowerVM REST API. All hypervisor operations interact with the PowerVM REST API via this binding. The driver is maintained to support future revisions of the PowerVM REST API as needed.

For ephemeral disk support, either a Virtual I/O Server hosted local disk or a Shared Storage Pool (a PowerVM clustered file system) is supported. For volume attachments, the driver supports Cinder-based attachments via protocols supported by the hypervisor (e.g. Fibre Channel).

For networking, the networking-powervm project provides Neutron ML2 Agents. The agents provide the necessary configuration on the Virtual I/O Server for networking. The PowerVM Nova driver code creates the VIF for the client VM, but the Neutron agent creates the VIF for VLANs.

Automated functional testing is provided through a third party continuous integration system. It monitors for incoming Nova change sets, runs a set of functional tests (lifecycle operations) against the incoming change, and provides a non-gating vote (+1 or -1).

Developers should not be impacted by these changes unless they wish to try the driver.

Community Impact

The intent of this project is to bring another driver to OpenStack that aligns with the ideals and vision of the community. The intention is to promote this to core Nova.

Alternatives

No alternatives appear viable to bring PowerVM support into the OpenStack community.

Namespaces

In Liberty and Mitaka, the namespace of the out-of-tree driver is nova_powervm.virt.powervm. In Newton, it was moved to nova.virt.powervm. In Ocata, the new in-tree driver occupies the nova.virt.powervm namespace, and the out-of-tree driver is moved to nova.virt.powervm_ext. Ocata consumers have the option of using the in-tree driver, which will provide limited functionality until it is fully integrated; or the out-of-tree driver, which provides full functionality. Refer to the documentation for the nova.conf settings required to load the desired driver.

Live Migrate Data Object

In order to use live migration prior to Ocata, it was necessary to run the customized nova_powervm conductor to bring in the PowerVMLiveMigrateData object. In Ocata, this object is included in core nova, so no custom conductor is necessary.

Tempest Tests

Since the tempest tests should be implementation agnostic, the existing tempest tests should be able to run against the PowerVM driver without issue.

Tempest tests that require function that the platform does not yet support (e.g. iSCSI or Floating IPs) will not pass. These should be ommitted from the Tempest test suite.

A sample Tempest test configuration for the PowerVM driver has been provided.

Thorough unit tests exist within the project to validate specific functions within this implementation.

Functional Tests

A third party functional test environment has been created. It monitors for incoming nova change sets. Once it detects a new change set, it will execute the existing lifecycle API tests. A non-gating vote (+1 or -1) will be provided with information provided (logs) based on the result.

API Tests

Existing APIs should be valid. All testing is planned within the functional testing system and via unit tests.

User Documentation

See the dev-ref for documentation on how to configure, contribute, use, etc. this driver implementation.

Developer Documentation

The existing Nova developer documentation should typically suffice. However, until merge into Nova, we will maintain a subset of dev-ref documentation.