Updated on 27 DEC 2019 VMware Integrated OpenStack 6.0 | 24 DEC 2019 | Build 15330102 Check for additions and updates to these release notes. |
Important Notice:
VMware Integrated OpenStack 6.0 build 14501926, released on September 3, 2019, has been replaced with VMware Integrated OpenStack 6.0 build 15330102. Ensure that you use the new build 15330102 for all future installations and upgrades. If you have already installed VMware Integrated OpenStack 6.0 build 14501926, see KB 76669 to patch your existing environment.
What's in the Release Notes
The release notes cover the following topics:- About VMware Integrated OpenStack
- What's New
- Compatibility
- Upgrading to Version 6.0
- Deprecation Notices
- Internationalization
- Open Source Components for VMware Integrated OpenStack
- Known Issues
About VMware Integrated OpenStack
VMware Integrated OpenStack greatly simplifies deploying an OpenStack cloud infrastructure by streamlining the integration process. VMware Integrated OpenStack delivers out-of-the-box OpenStack functionality and an easy configuration workflow through a deployment manager that runs as a virtual appliance in vCenter Server.
What's New
- OpenStack Stein: VMware Integrated OpenStack 6.0 is based on the Stein release of OpenStack.
- Support for the latest versions of VMware products: VMware Integrated OpenStack 6.0 supports and is fully compatible with VMware vSphere 6.7 Update 3, NSX Data Center for vSphere 6.4.5, NSX-T Data Center 2.5, vSAN 6.7, vRealize Log Insight 4.8.0 and vRealize Operations Manager 7.5.
- Intent-based control plane, featuring the following:
- Microservices architecture: All OpenStack services and VMware Integrated OpenStack management services are containerized and managed by Kubernetes.
- Dynamic scaling: The control plane can be scaled out and the number of service instances can be scaled in or out after VMware Integrated OpenStack has been deployed.
- Smaller footprint: Installation is more lightweight, and the control plane requires fewer compute, memory, and IP address resources than previous versions.
- Faster deployment and configuration: The time required to deploy OpenStack is greatly reduced, and reconfiguration after any day-2 operation is completed more quickly.
- Standards-based lifecycle management APIs: Configuration and lifecycle management are based on Kubernetes extensions and custom resources, enabling integration with fully open and standardized APIs.
- Improved user interface: VMware Integrated OpenStack now has an independent HTML5-based web interface that is decoupled from the vSphere Client. In addition, the
viocli
command-line utility has more consistent syntax, tab completion, and supports version control for resource configuration. See Comparison of Command-Line Operations for details and update any scripts accordingly. - NSX Policy Manager support: VMware Integrated OpenStack now supports the NSX-T Data Center Policy Manager as a networking back end.
- IPv6 support: With the NSX Policy Manager back end, the VMware Integrated OpenStack data plane can support IPv6. This support includes the following features:
- Static IPv6 address binding
- Stateless address autoconfiguration (SLAAC)
- Neutron security groups
- Firewall as a service (FWaaS)
- IPv6 and dual stack interfaces on Neutron routers
- Static routing on Neutron routers
- Route redistribution without source NAT on Neutron routers
- Backup scheduling: Administrators can now schedule backups of VMware Integrated OpenStack that leverage vSphere content libraries instead of NFS storage.
- OpenStack features:
- Cinder volumes can be created as First Class Disks (FCDs), removing the need for shadow VMs and increasing performance for certain volume operations.
- Cinder volumes can be attached to multiple instances simultaneously.
- Glance supports multiple back ends and multi-upload.
- Keystone identity federation supports multiple identity providers.
- VMware Essential PKS integration:
- Essential PKS is fully supported with VMware Integrated OpenStack 6.0 as the infrastructure provider for a fully supported container and IaaS hybrid environment.
- OpenStack integration for Kubernetes is available through the Kubernetes community OpenStack Cloud Provider.
- Integration with NSX-T Data Center is enabled and supported with the NSX Container Plugin.
- Example Heat templates are available that simplify deploying Essential PKS and NSX together with VMware Integrated OpenStack and enable simple cluster creation by administrators and tenants.
- VMware Photon operating system: The VMware Integrated OpenStack control plane virtual machines used as the Kubernetes worker nodes are based on the Photon operating system, providing enhanced security and uniform package management from VMware.
Compatibility
See the VMware Product Interoperability Matrices for details about the compatibility of VMware Integrated OpenStack with other VMware products, including vSphere components.
Upgrading to Version 6.0
You can upgrade directly to VMware Integrated OpenStack 6.0 from VMware Integrated OpenStack 5.1. See Upgrade VMware Integrated OpenStack.
If you are running VMware Integrated OpenStack 5.0 or an earlier version, first upgrade to version 5.1 and then upgrade to version 6.0.
Deprecation Notices
- VMware Integrated OpenStack with Kubernetes has reached the end of availability and is no longer included as of this version.
- VMware Integrated OpenStack is no longer certified with vRealize Automation as of this version, except as a generic OpenStack endpoint.
- The OpenStack Management Server APIs are no longer offered as of this version. The current Kubernetes-based APIs will be published at a later date.
- The following networking features have been deprecated and will be removed in a future version:
- The NSX Data Center for vSphere driver for Neutron.
- The NSX-T Manager driver for Neutron. In the future, the NSX-T Policy Manager driver will be used.
- The TVD plugin, which allows a single VMware Integrated OpenStack deployment to use an NSX Data Center for vSphere back end and a NSX-T Data Center back end.
- Neutron LBaaS has been deprecated and will be replaced in a future version by the OpenStack Octavia project.
Internationalization
VMware Integrated OpenStack 6.0 is available in English and seven additional languages: Simplified Chinese, Traditional Chinese, Japanese, Korean, French, German, and Spanish.
The following items must contain only ASCII characters:
- Names of OpenStack resources (such as projects, users, and images)
- Names of infrastructure components (such as ESXi hosts, port groups, data centers, and datastores)
- LDAP and Active Directory attributes
Open Source Components for VMware Integrated OpenStack
The copyright statements and licenses applicable to the open source software components distributed in VMware Integrated OpenStack 6.0 are available on the Open Source tab of the product download page. You can also download the disclosure packages for the components of VMware Integrated OpenStack that are governed by the GPL, LGPL, or other similar licenses that require the source code or modifications to source code to be made available.
Known Issues
- Public API rate limiting is not available.
In VMware Integrated OpenStack 6.0, it is not possible to enforce rate limiting on public APIs.
Workaround: None. This feature will be offered in a later version.
- If the image metadata vmware:extra_config has been configured, the flavor extra spec vmware_extra_config does not take effect.
If you set the vmware:extra_config metadata on an image, the vmware_extra_config extra spec on the flavor will be ignored even when the specific extra_config values of the image metadata and flavor extra spec do not conflict.
Workaround: Configure all desired extra_config values either in the image metadata only or in the flavor extra spec only.
- The log analytics server information may be displayed after the server has been removed.
If you configure a log analytics server when deploying OpenStack and later remove the server from your deployment, the log analytics IP address may still be displayed on the Integrated OpenStack Manager web interface.
Workaround: None. Although the IP address is still displayed, the server has been removed from your deployment.
- Migrating an instance with an attached volume may cause the volume to be deleted.
If an instance and its attached volume are located on different datastores, and you migrate the instance to the datastore currently containing the volume, the volume will be deleted.
Workaround: Do not migrate an instance to a datastore that contains a volume attached to the instance being migrated. Select another datastore.
- Removing a compute cluster with instances and later adding it again may fail.
If you remove a compute cluster from your deployment without first deleting all instances from that cluster, stale entries remain in the Nova database. If you then add the cluster under a different name, the operation may fail. Due to differences in naming conventions, this issue will occur if you delete a compute cluster added in a previous version of VMware Integrated OpenStack and re-add it to your deployment in VMware Integrated OpenStack 6.0.
Workaround: Remove all instances from a compute cluster before removing the cluster from your deployment.
- Snapshots on a controller node prevent the node from being migrated properly.
The persistent volume on a controller node cannot be moved if a snapshot of the controller node exists. Taking a snapshot of a controller is not supported.
Workaround: Delete all snapshots on controller nodes.
- For NSX-T Data Center deployments, a maximum of 125 allowed IP address pairs can be updated in a single operation.
The NSX-T Data Center back end supports a maximum of 128 IP addresses on a single port, including fixed IP addresses and allowed IP address pairs. When you use the Neutron command-line interface to update a port, entering more than 125 allowed IP address pairs in a single operation is not supported.
Workaround: None.
- vCenter Server instances that contain no compute clusters are not retained during upgrade.
If your existing deployment includes vCenter Server instances from which no compute nodes have been added to your deployment, the settings for those vCenter Server instances are not retained after you upgrade to VMware Integrated OpenStack 6.0.
Workaround: Add the desired vCenter Server instances to your VMware Integrated OpenStack 6.0 deployment after the upgrade is finished.
- Log files may not be retained when pods are restarted.
If you perform an operation, such as a configuration change, that results in pods restarting, the log files from those pods may be deleted.
Workaround: Use VMware vRealize Log Insight or another compatible log analytics platform to ensure log persistence.
- For NSX-T Data Center deployments, Layer 7 polices for LBaaS may not be enforced.
NSX-T Data Center does not support per-pool session persistence profiles. The Layer 7 policy of any pool other than the default pool of the target server does not take effect.
Workaround: None.
- If incorrect credentials are entered when deploying OpenStack, the wizard may fail to recognize correct credentials.
During the OpenStack deployment process, if vCenter Server or NSX Manager credentials are entered incorrectly, the wizard may fail to recognize correct credentials. Even if you remove the incorrect information and enter the correct credentials, the wizard may fail to validate them.
Workaround: Close the deployment wizard and open it again.
- Volumes created from images are always bootable by default.
If you include the --non-bootable parameter when creating a volume from an image, the parameter does not take effect.
Workaround: After the volume has been created, update it to be non-bootable.
- After you upgrade to VMware Integrated OpenStack 6.0, a default pool cannot be added to existing LBaaS listeners.
VMware Integrated OpenStack 5.x does not support changing the default pool of an LBaaS listener. This feature is supported in VMware Integrated OpenStack 6.0. However, if you create an LBaaS listener in VMware Integrated OpenStack 5.x that does not have a default pool, you cannot add a default pool to the listener even after upgrading to VMware Integrated OpenStack 6.0.
Workaround: Delete the affected listener and create it again.
- A deployment may remain in the "Waiting for controllers" state even after all controller nodes have been created.
A controller node may be successfully deployed in vSphere but time out before joining the controller cluster in VMware Integrated OpenStack. You can run the
kubectl get nodes
command to identify which controller nodes have joined the cluster.Workaround: In vSphere, delete the virtual machine corresponding to the controller node that failed to join the cluster. VMware Integrated OpenStack will then automatically recreate the node.