Comparing Red Hat OpenStack Platform

and Canonical’s Charmed OpenStack

July 2020

Introduction
OpenStack is an essential component of every modern organisation which uses
private cloud infrastructure for better economics, improved security and a
higher level of flexibility. Over the last few years, it has evolved and become a
de-facto standard for implementing cloud computing platforms. It is one of the
three most active open source projects in the world with 1,003 developers from
188 organisations involved in the Ussuri release development. According to
451 Research’s Market Monitor from September 2019, it’s combined market
size worldwide is $7.7BN.

Of the many companies involved in OpenStack development, Red Hat and

Canonical are leaders. According to the OpenStack User Survey Report from
2018, both companies have been powering over 70% of production clouds
together outside of the China market. Red Hat and Canonical each offer their
own production-grade OpenStack distribution and have built substantial
customer portfolios across various market sectors. However, this has been
achieved using a completely different approach towards OpenStack
deployments, operations and support.

This whitepaper performs a detailed comparison of Red Hat OpenStack Platform

and Canonical’s Charmed OpenStack. We show how the differences in both
distributions impact the business value brought by OpenStack to organisations in
terms of lower capital and operational costs, increased flexibility and simplicity of
use. Finally, we demonstrate that choosing the right OpenStack distribution is an
important decision for organisations planning to deploy OpenStack, as the wrong
choice may result in implementation delays, vendor lock-in and an inflating TCO
(total cost of ownership).
 An overview
This whitepaper starts with a brief overview of both companies and their
OpenStack distributions. Each of them has a different structure, work culture and
mission. Both are leaders in open source and OpenStack but with different
business models. The information below provides context to help understand the
differences in the distributions.

About Red Hat

Red Hat’s mission is to provide open source technologies for enterprises. Its
business model is based on licensing their proprietary software components
added on the top of existing open source technologies, such as Linux or
OpenStack, and providing commercial support for them. Red Hat is one of the
main contributors to OpenStack, primarily focusing on exploring incubating
projects. The company provides a rich portfolio of enterprise software products.
Those include RHEL (Red Hat Enterprise Linux), Red Hat OpenStack Platform, Red
Hat VIrtualization, Red Hat OpenShift, Red Hat Ceph Storage, Red Hat Satellite
and Red Hat Ansible Automation Platform.

About Canonical

Canonical’s mission is to deliver, maintain, secure and sustain open source

software from cloud to desktop and devices. The company is the publisher and
maintainer of Ubuntu, the most popular Linux distribution, and provides a rich
portfolio of software for enterprises, mid-size and small businesses, and
individuals. Those include Charmed OpenStack, Charmed Kubernetes, Charmed
Ceph, Landscape, MAAS, Juju, MicroK8s and Kubeflow. Its business model is
based on providing commercial support for those products. Canonical is actively
involved in OpenStack development, primarily focusing on improving the stability
of core OpenStack components.

Red Hat OpenStack Platform

Red Hat OpenStack Platform is a commercial OpenStack distribution offered by

Red Hat for enterprises. Its primary focus is to provide an OpenStack platform
that is stabilised according to enterprise needs. Red Hat OpenStack Platform is
primarily based on the TripleO (OpenStack on OpenStack) upstream project but
requires Red Hat’s proprietary components to be included in order to get
support. TripleO aims to use the same technologies to deploy OpenStack itself
that OpenStack uses to provision virtual machines. The platform follows the same
conservative approach as RHEL, providing support for the latest OpenStack
release with a significant delay for ensuring stability. Red Hat offers their
OpenStack distribution across different market sectors, including enterprises,
financial institutions and telcos. Cited customers include BBVA, Verizon, Turkcell
and Paddy Power Betfair.

2
 Canonical’s Charmed OpenStack

Canonical’s Charmed OpenStack is a 100% open source OpenStack distribution

that is publicly available for everyone. Canonical’s mission is to provide OpenStack
that can be deployed, maintained and upgraded economically. The distribution is
fully based on the OpenStack Charms upstream project and always becomes
available within two weeks of the upstream release for the latest features and
bug fixes while ensuring stability through constant testing and patching. For
enterprise customers looking for commercial support, Canonical offers
consulting, support and fully managed services for Charmed OpenStack. The
customer portfolio spans various market sectors, from enterprises, financial
institutions and telcos to governments. Canonical’s OpenStack customers include
Cisco, BT, Rabobank, Bloomberg and Tesco.

Distribution comparison
In the following section, we will perform a detailed analysis of the differences
between Red Hat OpenStack Platform and Canonical’s Charmed OpenStack. We
will evaluate how each distribution influences and impacts the business value
OpenStack can deliver to an enterprise. For a more detailed comparison, refer to
the appendix at the end of this whitepaper.

Licensing

We start the comparison by looking at licensing. While OpenStack itself is 100%

open source, various OpenStack distributions may rely on tools which are not
open source and require a subscription. For example, OpenStack vendors may use
their proprietary tools to install and operate OpenStack. This results in vendor
lock-in and prevents users from leveraging the benefits of open source software.
For example, if there is a bug in the OpenStack installer, they are dependent on
the vendor to fix this bug, rather than fixing it themselves or benefitting from a
community member doing so. Being fully vendor-dependent results in reduced
flexibility, time spent on looking for and applying workarounds or can even lead
to situations where the production cloud is not operational at all.

One such OpenStack distribution is Red Hat OpenStack Platform. Although the
underlying engine, TripleO, is open source and hosted under the governance of
the OpenStack Foundation, Red Hat packages their OpenStack Platform with a
proprietary installer. This installer, called Red Hat OpenStack Platform Director,
provides an additional layer on top of TripleO and requires a subscription to be
purchased. This stack is shown in Fig. 1. Although Red Hat provides a trial period
during which organisations can try Red Hat OpenStack Platform for free, the
entire platform cannot be used after the trial period expires. This means that
organisations have to cover all of their environments, including production,
development and staging, with the subscription. This subscription, as we will
show in the next section, is expensive.

3
 Red Hat OpenStack
Platform Director
OpenStack
Charms
TripleO

OpenStack OpenStack No subscription required

Subscription required

Red Hat Canonical’s

OpenStack Platform Charmed OpenStack

Fig.1. Red Hat OpenStack Platform and Canonical’s Charmed OpenStack software stack.

In turn, Canonical’s Charmed OpenStack is 100% open source. It is fully based on

OpenStack Charms which are an official OpenStack project hosted under the
governance of the OpenStack Foundation. This provides absolute transparency
and helps to stay compliant with the upstream. Moreover, Charmed OpenStack
does not require a subscription which means that organisations can try it and use
it free of charge for as long as they need. For enterprise customers, Canonical
provides consulting, support and fully managed services for OpenStack if desired,
but organisations can re-use the artefacts provided by Canonical to deploy as
many clouds as they want. They can also decide which environments to cover with
the subscription that may result in substantial cost savings as usually, not all
environments require full support. This results with increased flexibility in
budgeting private cloud infrastructure.

Pricing model

Although not all OpenStack vendors require a subscription for usage of their
distribution, all of them rely on the subscription to provide commercial support.
This is where the pricing becomes a decisive factor. Every organisation, regardless
of size, wants to receive the best possible services with the best economics.

Red Hat only supports OpenStack deployments made through the Red Hat
OpenStack Platform Director. Various types of subscriptions, including Red Hat
OpenStack Platform, Red Hat OpenStack Platform (without a guest OS) and Red
Hat Ceph Storage are available, depending on the node destination. Although
Red Hat’s pricing for OpenStack is not publicly available, an estimated price of a
Red Hat OpenStack Platform subscription unit is 5,000 USD per socket-pair. In
addition, all nodes in the cluster have to be covered with a RHEL subscription at
the price of 1,299 USD per socket-pair.

A per socket-pair pricing model means that a separate subscription is needed for
every 2 CPUs (central processing units). As a result, the cost increases as the
number of workloads grow, making this an expensive option when scaling. In turn,
Canonical uses a per host pricing model, regardless of the number of CPUs inside
of the host, under the Ubuntu Advantage for Infrastructure (UA-I) subscription.
This means that if the number of workloads grows, Canonical’s customers can just
switch to more powerful hardware instead of purchasing additional subscriptions,
as adding and removing hardware is fully automated, including bare metal
provisioning. They can also plan the deployment carefully without having to
purchase more subscriptions than they actually need during the initial roll-out of
the cloud.
4
 The difference between per socket-pair and per host pricing model, based on a
compute node example, is shown in Fig. 2:

a. One host with 2 CPUs

Canonical: 1 subscription
(1,500 USD)
Red Hat: 1 subscription
(˜6,300 USD)

CPU CPU

b. Two hosts with 1 CPUs

Canonical: 2 subscription
(3,000 USD)
Red Hat: 2 subscription
(˜12,600 USD)

CPU CPU

c. Two hosts, each with 8 CPUs

Canonical: 2 subscription
CPU CPU CPU CPU (3,000 USD)
Red Hat: 8 subscription
(˜50,400 USD)
CPU CPU CPU CPU

CPU CPU CPU CPU

CPU CPU CPU CPU

Fig.2. Per socket-pair vs per host pricing model.

The biggest problem with the per socket-pair pricing model is the lack of
transparency and control over the costs compared to the per host pricing model.
It is much easier to predict the growth rate of physical hosts than the growth rate
of socket-pairs. This is especially true in environments where virtual machines
have dedicated CPUs assigned, such as NFVI (network function virtualisation
infrastructure) scenarios. As a result, a per socket-pair pricing model can quickly
result in an ever-inflating TCO. Per host pricing allows enterprises to thoroughly
estimate annual operational costs and enables full transparency when budgeting
for future changes.

5
 Ubuntu Advantage for Infrastructure (UA-I) is an enterprise subscription for
Ubuntu, covering all aspects of the infrastructure, including Ubuntu Server,
OpenStack, Ceph and Kubernetes. It includes commercial support, production-
grade SLAs (service level agreements), Kernel Livepatch Service and up to 10 years
of security patches. Ubuntu Advantage for Infrastructure is available in three
variants: Essential, Standard and Advanced, each of which offer different levels of
support. The annual cost of an Advanced subscription is 1,500 USD per host.

Consulting services

OpenStack is known to be a complex system. Although the installers which are

usually available as part of commercial distributions significantly simplify its initial
deployment, organisations which have no previous experience with OpenStack
still struggle with designing the cloud and making choices of hardware, SDN
(software-defined networking) controllers and storage platforms. This slow
decision making and implementation process could be invested in utilising
OpenStack to bring value to the business. In response to this challenge, various
OpenStack vendors offer consulting services for their distributions.

Red Hat’s approach towards consulting for OpenStack is to engage with potential
customers through an SDF (solution delivery framework) which consists of three
stages: discover, design and deploy. Across these stages, Red Hat consultants
provide products, services and custom engagements to help their customers
design and build their private cloud infrastructure based on the Red Hat
OpenStack Platform. The pricing is calculated individually based on consulting
units which are credits that can be redeemed for consulting services. This means
that the customer pays for work hours of Red Hat’s consultants instead of the
actual deliverables. This can lead to budgeting challenges as customers often do
not know how many consulting units are needed to meet their requirements. An
estimated price of Red Hat OpenStack Platform delivery is 10,000 USD per week
of engagement with a Red Hat consultant.

Instead of building snowflakes, Canonical takes a completely different approach

to OpenStack design and delivery. For its customers, Canonical offers the Private
Cloud Build (PCB) service at a fixed price. The service includes a reference
architecture, BOM (bill of materials) for various choices of certified hardware and
Charmed OpenStack delivery. For more demanding customers, Canonical offers
the Private Cloud Build Plus service which expands the PCB service with on-site
design workshops to prepare an optimal, customised design that meets
customers’ needs. By consuming consulting services at a fixed price, organisations
benefit from a transparent and predictable cost.

Private Cloud Build (PCB) is a consultancy package for Charmed OpenStack which
includes cloud delivery based on reference architecture and certified hardware
options. Additional services and add-ons, such as on-site design workshops, custom
architecture and non-standard SDN, and storage solutions are available under the
PCB Plus package. Using PCB leverages the Infrastructure-as-Code (IaC) approach,
making the deployments repeatable and drastically reduces the time required to
deploy OpenStack. PCB is available at a fixed price and costs 75,000 USD.

6
 Support services

While consulting services allow organisations to accelerate the initial roll-out of

their OpenStack cloud, support services allow them to stay updated post-
deployment and use help when needed. Both Red Hat and Canonical offer
commercial support for their OpenStack distributions. These include bug fixes,
security patches, production-grade SLAs and ongoing support. Everything that is
needed for a production OpenStack.

So is there anything that differentiates Red Hat OpenStack Platform from

Canonical’s Charmed OpenStack with regards to the commercial support? Apart
from Canonical offering a more economical support model with predictable
pricing as shown in Fig.2, the only difference between the two is the maximum
support timeline. While Red Hat provides five years of support for their
OpenStack distribution, Canonical commits to provide security patches for
Charmed OpenStack for an additional five years as part of the ESM (Extended
Security Maintenance) package available for enterprise customers under the
Ubuntu Advantage for Infrastructure subscription. This results in up to ten years
of security and provides enterprises with the flexibility to plan their upgrade
while staying patched.

Managed services

In some situations, organisations may not be ready to operate

Managed OpenStack is a fully managed OpenStack post-deployment by themselves. This is because
private cloud service provided by OpenStack usually requires dedicated human resources to
Canonical which enables organisations maintain it. Although large enterprises usually have a dedicated
to fully outsource their OpenStack operations team or can afford to hire as needed, this may not be
operations. Managed OpenStack the case for mid-size and small businesses. Moreover, even if they
includes daily OpenStack maintenance, have resources, organisations may still face other challenges
upgrades, monitoring and incident, when operating OpenStack. These include lack of knowledge,
and problem resolution. The annual lack of experience, lack of on-prem conditions to host the cloud
cost of the Managed OpenStack or time constraints. All of that results in a lot of time spent on
service is $4,275 USD per host. learning new technologies and prevents organisations benefiting
from the value brought by OpenStack immediately.

In response to the aforementioned challenges, some OpenStack vendors offer

fully managed services for their distribution. Managed OpenStack solutions fill in
the gaps between the business and the technology and allow organisations to
fully transfer the risk associated with OpenStack operations. In order to be able
to offer such services, OpenStack vendors usually require that the cloud is
deployed by them through the consulting services. However, in most cases,
organisations can take control of their cloud at any given time and terminate the
contract when no longer needed.

This is exactly what Canonical offers for its Managed OpenStack service. Although
the cloud is deployed by Canonical’s field engineers as a part of the PCB service
and is maintained by Canonical’s operations team, customers can always request a
handover. This is also something that Canonical can help with by offering
comprehensive training services for customer’s operations team members. In
turn, Red Hat does not offer managed services leaving their customers on their
own with post-deployment maintenance. Moreover, as the cumulative cost of
UA-I and Managed OpenStack (5,775 USD per host) is lower than the cumulative
cost of Red Hat subscription for OpenStack (~6,300 USD per socket-pair), in fact
Canonical’s customers can get fully managed private cloud service at a better
price than Red Hat’s OpenStack customers.
7
 OpenStack maintenance

Although fully managed services for OpenStack are a tempting solution for
many organisations, due to various reasons they are not always an option.
While most organisations rely on vendor’s consulting services to deploy
OpenStack, they usually maintain the cloud by themselves post-deployment.
How easy this maintenance is becomes a decisive factor. As OpenStack
maintenance includes lifecycle management, configuration, daily operations
and integration with external components, a lot of resources are required to
operate it. In most cases, a dedicated team is hired to maintain the cloud.
An organisation then needs to evaluate how many employees are required
which will impact its ongoing OpEx costs.

While Red Hat OpenStack Platform Director provides full automation of the initial
OpenStack deployment process, its support for ongoing OpenStack maintenance
is very limited. Most of the tasks, such as scaling out the cluster, have to be either
run manually or in a semi-automated way. In turn, Charmed OpenStack expands
automation to daily OpenStack maintenance by using a model-driven approach
based on OpenStack Charms. This is possible by abstracting the entire complexity
behind OpenStack and exposing the configuration of the cloud in the form of a
model which can be easily updated by the operations team. As a result,
organisations have to spend less time performing daily maintenance tasks. This
means that fewer FTEs (full-time equivalents) are required to operate the cloud
which results in significant cost savings.

Release cadence

OpenStack is a quickly evolving project, thus it is released according to well-

defined release cadence. A new version of OpenStack becomes available every six
months. This allows OpenStack users to estimate feature delivery timelines,
design an upgrade plan for and apply it at any given time in the future. However,
not all OpenStack distributions follow the upstream release process with the
same predictability.

Historically, Red Hat’s release cadence was not predictable at all. Although
starting with OpenStack Platform 16, Red Hat now commits to release new
versions of their OpenStack distribution on a regular basis, support for the latest
upstream OpenStack version is still coming with a few months delay. This is
because the release cadence of Red Hat OpenStack Platform follows the same
conservative approach that the company applies for RHEL; striving to ensure
stability over anything else.

However, Canonical commits to release new versions of Charmed OpenStack

within two weeks from the upstream release. This means that customers can
upgrade to the latest stable upstream version shortly after it becomes available.
As new versions usually come with a lot of new features, various enhancements
and bug fixes, the sooner organisations can access them, the sooner they can
start extracting the business value brought by them. At the same time, stability is
ensured through the constant integration testing and patching process. The
Charmed OpenStack release cadence is shown in Fig. 3.

8
 OpenStack Y LTS

Ubuntu 22.04 LTS

OpenStack Y

OpenStack X

OpenStack W

OpenStack Victoria

OpenStack Ussuri LTS

Ubuntu 20.04 LTS

OpenStack Ussuri

OpenStack Train

OpenStack Stein

OpenStack Rocky

OpenStack Queens LTS

Ubuntu 18.04 LTS

OpenStack Queens

OpenStack Mitaka LTS

Ubuntu 16.04 LTS

2016 2018 2020 2022 2024 2026 2028 2030 2032

Tech preview
Ubuntu LTS release Standard Support
Matching OpenStack release support
Extended support for customers
Extended support maintenance

Fig. 3. Charmed OpenStack release cadence.

OpenStack upgrades

Software upgrades are an essential part of the maintenance process. The same
practice should apply to OpenStack. However, OpenStack upgrades are known to
be very complex. This is because OpenStack consists of various interconnected
components which have to work together to provide the service to users. Thus,
the upgrade procedure has to be executed very carefully as a failure of a single
step results in a failure of the entire process. As a result, many OpenStack vendors
have never supported OpenStack upgrades, forcing their customers to re-deploy.
Re-deployments usually translate to downtime and additional work - scenarios
that organisations usually want to avoid.

Historically, Red Hat was not supporting OpenStack upgrades at all. This was
partially due to the fact that they have been constantly changing the underlying
software stack for OpenStack installation. However, starting from Red Hat
OpenStack Platform 16 upgrades are now supported. Red Hat provides a manual
procedure which users can use to upgrade their cloud. This is not ideal, however,
as the procedure is very complex and time-consuming. Moreover, its complexity
increases as the size of the cloud grows. Not to mention very complex
architectures such as those used by telcos, for example.

Canonical was one of the first OpenStack vendors offering full support for
OpenStack upgrades. Canonical’s Charmed OpenStack can be upgraded in a fully
automated way. The operations team only has to initialise the upgrade process
manually and the rest of the work is performed by OpenStack Charms. This is
again possible by abstracting the entire complexity behind OpenStack and hiding
it from the operations team. Fully automated upgrades allow organisations to
stay up to date while meeting their availability goals. All of that results in less
work required to maintain the cloud and reduced operational cost.

9
 Multi-cloud and hybrid clouds

Although OpenStack on its own is an essential part of every modern organisation

that uses a private cloud, a multi-cloud strategy is increasingly a consideration.
This is especially evident in the case of containers as the entire world is moving
towards cloud-native applications. Therefore, how to run containers on top of
OpenStack becomes an important question. Moreover, many organisations
implement a hybrid approach, running sensitive workloads in the private cloud,
while outsourcing others to public clouds. How easy the private cloud can be
integrated with public clouds becomes another decisive factor.

Red Hat OpenStack Platform does not provide any integration capabilities with
public clouds out of the box. It is simply not designed for this purpose. As for
containers, Red Hat has been promoting their OpenShift PaaS (platform-as-a-
service) platform which uses Kubernetes underneath, but it is proprietary and
available per an additional license. This again leads to vendor lock-in and increased
operational costs as customers have to purchase a subscription for another
infrastructure component and are fully dependent on the vendor.

Canonical takes a completely different approach here. The company believes in a

multi-cloud partnership on Kubernetes for the purpose of running cloud-native
applications. Canonical’s Charmed OpenStack can be easily extended with
Charmed Kubernetes services running on top of it and the entire stack is
supported under the same Ubuntu Advantage for Infrastructure subscription.
This means that organisations do not have to pay extra for support of the
container coordination platform, benefitting from a single platform for both
virtual machines and containers. Canonical’s Charmed OpenStack and Charmed
Kubernetes can also be easily integrated with other charmed applications running
in public clouds, leading to a fully functional hybrid cloud based on the same
software stack.

Security and compliance

Last but not least, security plays an important role in every organisation. Red
Hat’s approach towards security has always been based on relying on mature
versions of the kernel and software. Being very conservative with regards to new
RHEL releases and adopting new versions of OpenStack with a significant delay,
Red Hat has prioritised stability over new features. But is stability the only
guarantor of security? Not really and Ubuntu Server is proof of that.

By always using a new stable Linux kernel, prioritising CVE (common

vulnerabilities and exposures) and applying security patches 24/7, Ubuntu Server
is known to be the most secure enterprise Linux distribution. An additional layer
of security can be introduced by using CIS (Center of Internet Security) hardened
images. By running on the top of Ubuntu Server, Canonical’s Charmed OpenStack
provides the highest possible level of security.

Ubuntu Advantage for Infrastructure customers also receive access to the Kernel
Livepatch Service which allows applying kernel patches on the fly, without
rebooting the operating system. This results in improved stability and resiliency
as OpenStack services are not affected. Finally, the entire Charmed OpenStack
can be integrated with Canonical’s Landscape service which provides the ability to
perform security audits and generate compliance reports. It also provides
traditional operating system administration capabilities for bare-metal machines,
virtual machines and containers.

10
 Conclusion
Although both Red Hat OpenStack Platform and Canonical’s Charmed OpenStack
are production-grade commercially supported OpenStack distributions, they
differ substantially. Those differences result from distinct missions and business
models of the companies behind them. While Red Hat provides an OpenStack
distribution for enterprises, Canonical’s mission is to deliver an OpenStack
distribution that is deployable, maintainable and upgradable economically. At the
same time, Canonical provides consulting, support and fully managed services for
OpenStack, simplifies its deployments and operations, enables fully automated
upgrades and ensures a higher level of security.

In this whitepaper, we performed a detailed comparison of Red Hat OpenStack

Platform and Canonical’s Charmed OpenStack. We demonstrated that choosing
the right OpenStack distribution is important as the wrong choice may result in
delays, vendor lock-in and an increased TCO. Finally, we proved that Canonical’s
Charmed OpenStack is not only cheaper than Red Hat OpenStack Platform but
also provides a higher level of production readiness, required by enterprises,
telcos, financial institutions and governments.

11
Appendix
The following tables summarises the main differences between Red Hat OpenStack Platform and Canonical’s
Charmed OpenStack:

Red Hat OpenStack Platform Canonical’s Charmed OpenStack

Subscription Required Not required

Support pricing Per socket-pair (~6,300 USD) Per host (1,500 USD)

Availability of consulting services Yes, based on consulting units Yes, at a fixed price
(~10,000 USD per week) (75,000 USD)

Availability of managed services No Yes

Release cadence 6 months with an LTS 6 months with an LTS

every 18 months every 2 years

Maximum support timeline 5 years 10 years

Open source No Yes

OpenStack deployment Red Hat OpenStack Juju and OpenStack Charms

mechanism Platform Director

OpenStack upgrades Very complex manual procedure Fully automated

Bare-metal provisioning tool Ironic MAAS

Operating System Red Hat Satellite Landscape

management tool

Control plane Containerised (Kolla) Containerised (LXD)

Supported hypervisors KVM KVM, Hyper-V

Supported SDN platforms OVN, OVS, Juniper Contrail, OVN, OVS, Juniper Contrail,
Cisco ACI, OpenDaylight Cisco ACI, Nuage

Supported storage platforms Ceph, NFS Ceph, SAN, Nexenta, Pure

Storage, StorPool

12
 Learn more

For more information about Canonical’s Charmed OpenStack,

please visit our website.

You may also consider reading the following materials:

• OpenStack distribution comparison
• Private cloud TCO calculator
• Canonical’s consulting services for OpenStack datasheet
• Canonical’s support services for OpenStack datasheet
• Canonical’s managed services for OpenStack datasheet

To get in touch with Canonical about OpenStack, click here.

© Canonical Limited 2020. Ubuntu, Kubuntu, Canonical and their associated logos are the registered trademarks
of Canonical Ltd. All other trademarks are the properties of their respective owners. Any information referred
to in this document may change without notice and Canonical will not be held responsible for any such changes.
Canonical Limited, Registered in England and Wales, Company number 110334C Registered Office:
12-14 Finch Road, Douglas, Isle of Man, IM99 1TT VAT Registration: GB 003 2322 47