Platform9 3.9 release notes
Platform9 Managed Kubernetes
1. Kubernetes version upgrade to 1.11.5
This version of Platform9 Managed Kubernetes has upgraded the Kubernetes version from 1.10.11 to 1.11.5. You can find more info on this version, along with its various features, in the blog for the Kubernetes 1.11 release. Clusters can be upgraded to this Kubernetes version by using the “Upgrade Cluster” button in the Clusters view of the Infrastructure page of the Platform9 Clarity UI.
We highly recommend users upgrade their clusters at the earliest convenience and within 15 days of the release of new Platform9 Managed Kubernetes versions. Users may need to obtain a compatible kubectl for this version if their existing kubectl is not compatible with Kubernetes 1.11.5. See Install and Set Up kubectl for more information.
2. Availability of qbert v3 API
In this release, we are announcing the availability of the qbert v3 API. This API provides all the capabilities available with the Managed Kubernetes product. Users directly relying on the qbert API should move to using this version of the API in the near term. Note that the previous versions of the qbert API, namely v1 and v2, are going to be deprecated over the next 6 months.
3. Improvements to Clarity UI
There are several improvements to the Managed Kubernetes Clarity UI
- Improved workflow to create Kubernetes cluster for OpenStack deployments. Relevant OpenStack resources are discovered ahead of time to enable end users to select resoures from these discovered resources. This should eliminate errors with users providing wrong resource names or ids while creating a cluster.
- Managing tags for a Kubernetes cluster is more user-friendly.
- Notification at individual cluster level if there is an upgrade available for that cluster.
4. Update to AWS IAM policies required for Platform9 Managed Kubernetes
In this release, the Kubernetes AWS provider requires updates to the AWS capabilities granted to the AWS cloud providers’ account. Ensure this requirement is satisfied by the IAM policies for this user. You can find the latest IAM policy file How To Create a new Amazon AWS Cloud Provider for Managed Kubernetes support article.
5. Bug fixes
This release also contains a number of performance optimizations and bug-fixes that should result in a better user experience for your Platform9 cloud platform! Some significant ones are listed below
- Pods would be stuck in “Terminating” state when an unmount of a persistent volume would fail.
- Application Catalog would take a long time to load all the apps.
Platform9 Managed OpenStack
1. General availability of Neutron networking on VMware
This release introduces support for OpenStack Networking (neutron) on VMware. It is now possible to create and manage VMware Port Groups (OpenStack provider networks) on a VMware Distributed Virtual Switch using OpenStack’s Networking API.
With the introduction of OpenStack Networking, OpenStack legacy networking (nova-network) is no longer supported.
2. Glance project upgraded to Pike release
OpenStack Glance has been upgraded to the Pike release. This release brings a number of new features, critical bug fixes, and stability enhancements.
3. Designate project upgraded to Queens release
OpenStack Designate (DNSaaS service for OpenStack) has been upgraded to the Queens release. This release brings a number of new features, critical bug fixes, and stability enhancements. Any tooling using the Designate V1 API needs to be reworked to use the v2 API.
4. Bug fixes
This release also contains a number of bug fixes which should result in a better user experience for your Platform9 cloud platform! Some significant ones are listed below.
- DHCP leases are inadvertently released if a DHCP Request contains a client ID, and a corresponding client ID is not configured on the Instance’s port - https://bugs.launchpad.net/neutron/+bug/1806770.
- Instances created from volumes add to the local storage stats - https://bugs.launchpad.net/nova/+bug/1469179.
- Resource utilization statistics on the OpenStack Dashboard are not populated for Omni regions.
- UI fails to refresh security groups when switching tenant during Instance creation.
- VMHA enhancement to auto-balance consul cluster nodes with server role and agent role to maintain a quorum of servers.
5. Known limitations
- Omni does not discover security groups assigned to an Instance. As a result OpenStack will not accurately reflect the assigned security group. The Instance will appear within OpenStack as having the “default” security group although the actual Security Group assigned to the Instance in AWS remains unchanged.
- Changing Security Group of an instance after it has been created from OpenStack does not change the Security Group in EC2.
AWS allows adding multiple IP address ranges to a single security group rule. However, Omni will only discover the first IP range in the list, ignoring the additional ranges. If the discovered security group rule is updated from OpenStack, the IP ranges which were not discovered will be removed from the rule.
Workaround: Create multiple security group rules - one for each IP range.
Creating security group rules which reference other security groups does not work when the security group rule is created from Omni. The Omni conversion logic currently cannot convert an OpenStack ID to an AWS security group ID.
As a result, security group rules which reference other security groups will not be accurately discovered. The rule will be discovered with a source and destination of 0.0.0.0/0. If the discovered security group rule is updated from OpenStack, the correct rule definition in AWS will be overwritten with the incorrect data from OpenStack.
January 11, 2019
Thank you for your feedback! What did you like about this article?
Thank you for your feedback! How could this article be improved?
Thank you for your feedback!