CloudArchive
Size: 8899
Comment: Based on support times for non-LTS Ubuntu Server going to 9 months, we needed to reduce the support in the Cloud Archive. We compromised to 12 months at vUDS.
|
← Revision 109 as of 2025-03-27 08:08:22 ⇥
Size: 6135
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
<<Include(ServerTeam/Header)>> |
## page was renamed from ServerTeam/CloudArchive |
Line 7: | Line 6: |
Canonical’s Ubuntu Cloud archive allows users the ability to install newer releases of OpenStack on Ubuntu Server 12.04 LTS (and the dependencies) as they become available up through the next Ubuntu LTS release (presumably 14.04). Bug processing and patch contributions will follow standard Ubuntu practice and policy where applicable. Canonical commits to maintaining and supporting new OpenStack releases for Ubuntu Server 12.04 LTS in the Ubuntu Cloud archive for at least 12 months after they release. Canonical will stop introducing new releases of OpenStack for Ubuntu Server 12.04 LTS into the Ubuntu Cloud archive with the version shipped in the next Ubuntu Server LTS release (presumably 14.04). They will maintain and support this last updated release of OpenStack in the Ubuntu Cloud archive for 3 years, i.e. until the end of the Ubuntu 12.04 LTS lifecycle. | Canonical’s [[https://ubuntu-cloud.archive.canonical.com | Ubuntu Cloud Archive (UCA)]] gives users the ability to install backported !OpenStack versions on Ubuntu LTS releases. |
Line 9: | Line 8: |
In order to allow for relatively easy upgrades, and still adhere to Ubuntu processes and policy, Canonical elected to have archive.canonical.com be the home of the Ubuntu Cloud archive. They will enable update paths for each OpenStack release. | The [[https://wiki.ubuntu.com/Releases | Ubuntu]] and [[https://releases.openstack.org/ | OpenStack]] projects publish new releases every six months at approximately the same time. Each Ubuntu release therefore includes a new !OpenStack version by default. It is this !OpenStack version that is backported to the latest LTS via the UCA. The [[https://ubuntu.com/about/release-cycle#openstack-release-cycle | Ubuntu OpenStack release cycle]] graphic represents this scheme visually over time. |
Line 11: | Line 10: |
* e.g. Enabling “precise-folsom” in the archive will provide access to all OpenStack Folsom packages built for Ubuntu Server 12.04 LTS (binary and source), any updated dependencies required, and bug/security fixes made after release. | == SRU process == |
Line 13: | Line 12: |
As of now, Canonical has no plans to build or host OpenStack packages for non-LTS releases of Ubuntu Server in the Ubuntu Cloud archive. The chart below explains the options. | The [[OpenStack/StableReleaseUpdates | SRU process for OpenStack and the UCA]] is used during the development of a new UCA release and when backporting any updated dependencies and bug/security fixes to an existing UCA release. |
Line 15: | Line 14: |
{{attachment:plan.png}} | For example, in terms of a new UCA release, Ubuntu Lunar ships with !OpenStack 2023.1 Antelope by default. In this timeframe, the latest LTS is Ubuntu 22.04 (Jammy). Antelope packages (binary and source) are therefore backported to Jammy via the Antelope UCA release. In order for this to happen, individual Lunar packages are backported according to this staged process: |
Line 17: | Line 16: |
== How to Enable and Use == You'll first need to add the cloud archive gpg key into your ubuntu-keyring by running the following command: |
'''lunar -> antelope-staging -> antelope-proposed -> antelope-updates''' When backporting fixes to an existing UCA release the original Ubuntu release must also get the update: '''lunar-proposed -> antelope-staging -> antelope-proposed''' When Lunar reaches end-of-life, Antelope package updates will be uploaded directly to the Antelope UCA. This process can be monitored live with the [[https://openstack-ci-reports.ubuntu.com/reports/cloud-archive/index.html | Ubuntu Cloud Archive Tracker]]. It includes package versions for each of the above stages and for all UCA releases. The first column in the tracker is '''Ubuntu''' and represents the first stage in the above two scenarios. == Using the UCA == The release schedule of !OpenStack and Ubuntu are generally synchronised: a new !OpenStack release becomes available in the UCA every six months and coincides with each release of Ubuntu. As !OpenStack releases are added to the UCA and as releases fall out of support this section will be updated. A UCA !OpenStack release is enabled on a host with the `add-apt-repository` command (it is recommended to run `sudo apt update` both before and after). === Ubuntu 24.04 LTS === On 24.04, !OpenStack Dalmatian (non-SLURP) is supported for 9 months. ==== 2024.2 Dalmatian ==== |
Line 20: | Line 39: |
sudo apt-get install ubuntu-cloud-keyring | sudo add-apt-repository cloud-archive:dalmatian |
Line 23: | Line 42: |
Next, to get access to the Ubuntu Cloud archive, please add the following entries to your /etc/apt/sources.list: | === Ubuntu 22.04 LTS === |
Line 25: | Line 44: |
=== Folsom === {{{ # The primary updates archive that users should be using deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main |
On 22.04, !OpenStack Zed is supported for 18 months, !OpenStack Antelope for 36 months, and !OpenStack Bobcat (non-SLURP) is supported for 9 months. 24.04's default !OpenStack version (Caracal) is supported in the UCA for 36 months (i.e. until the end of the Ubuntu 22.04 LTS lifecycle). |
Line 30: | Line 46: |
# Public -proposed archive mimicking the SRU process for extended testing. # Packages should bake here for at least 7 days. #deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-proposed/folsom main |
==== 2024.1 Caracal ==== {{{ sudo add-apt-repository cloud-archive:caracal |
Line 35: | Line 52: |
=== Grizzly === {{{ # The primary updates archive that users should be using deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/grizzly main |
|
Line 40: | Line 53: |
# Public -proposed archive mimicking the SRU process for extended testing. # Packages should bake here for at least 7 days. #deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-proposed/grizzly main |
==== 2023.2 Bobcat ==== {{{ sudo add-apt-repository cloud-archive:bobcat |
Line 45: | Line 59: |
=== Havana === {{{ # The primary updates archive that users should be using deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/havana main |
==== 2023.1 Antelope ==== |
Line 50: | Line 61: |
# Public -proposed archive mimicking the SRU process for extended testing. # Packages should bake here for at least 7 days. #deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-proposed/havana main |
{{{ sudo add-apt-repository cloud-archive:antelope |
Line 55: | Line 65: |
Now run: | ==== Zed ==== |
Line 57: | Line 68: |
sudo apt-get update }}} to update your package listings and then proceed to install/upgrade your openstack packages. |
sudo add-apt-repository cloud-archive:zed }}} |
Line 61: | Line 71: |
== Reporting Bugs == | === Ubuntu 20.04 LTS === |
Line 63: | Line 73: |
To report bugs against packages from the Ubuntu Cloud Archive, please use the 'ubuntu-bug' tool, for example: | On 20.04, !OpenStack Victoria and !OpenStack Xena are supported for 18 months each, and !OpenStack Wallaby for 36 months. 22.04's default !OpenStack version (Yoga) is supported in the UCA for 36 months (i.e. until the end of the Ubuntu 20.04 LTS lifecycle). ==== Yoga ==== {{{ sudo add-apt-repository cloud-archive:yoga }}} ==== Xena ==== {{{ sudo add-apt-repository cloud-archive:xena }}} ==== Wallaby ==== {{{ sudo add-apt-repository cloud-archive:wallaby }}} === Ubuntu 18.04 LTS === On 18.04, !OpenStack Rocky and !OpenStack Train are supported for 18 months each, and !OpenStack Stein for 36 months. !OpenStack Ussuri, 20.04's default !OpenStack version, is supported in the UCA for 36 months (i.e. until the end of the Ubuntu 18.04 LTS lifecycle). ==== Ussuri ==== {{{ sudo add-apt-repository cloud-archive:ussuri }}} == Ceph and the UCA == The below table shows the relationship between UCA release, Ceph release, Ubuntu LTS release, and Ubuntu default archive ("distro"). || '''Ceph release''' || '''Default archive''' || '''UCA release''' || '''Ubuntu LTS release''' || || Squid || yes || - || Noble || || Squid || - || jammy-caracal || Jammy || || Reef || - || jammy-bobcat || Jammy || || Quincy || yes || - || Jammy || || Quincy || - || focal-yoga || Focal || || Pacific || - || focal-xena || Focal || || Pacific || - || focal-wallaby || Focal || || Octopus || yes || - || Focal || || Octopus || - || bionic-ussuri || Bionic || || Nautilus || - || bionic-train || Bionic || || Mimic || - || bionic-stein || Bionic || || Mimic || - || bionic-rocky || Bionic || || Luminous || yes || - || Bionic || || Luminous || - || xenial-queens || Xenial || || Jewel || yes || - || Xenial || || Jewel || - || trusty-mitaka || Trusty || || Firefly || yes || - || Trusty || == Reporting a bug == To report bugs against packages from the UCA, please use the `ubuntu-bug` tool. For example: |
Line 69: | Line 136: |
This will ensure that bugs are raised against the cloud-archive project on Launchpad. == Q & A == === Why Not Use Stable Release Updates? === Ubuntu's release policy states that once an Ubuntu release has been published, updates must follow a special procedure called a stable release update, or SRU, and are delivered via the -updates archive. These updates are restricted to a specific set of characteristics: * severe regression bugs * security vulnerabilities (via the -security archive) * bugs causing loss of user data * "safe" application layer bugs * hardware enablement * partner archive updates Exceptions to the SRU policy are possible. However, for this to occur the Ubuntu Technical Board must approve the exception, which must meet their guidelines: * Updates to new upstream versions of packages must be forced or substantially impelled by changes in the external environment, i.e. changes must be outside anything that could reasonably be encapsulated in a stable release of Ubuntu. Changes internal to the operating system we ship (i.e. the Ubuntu archive), or simple bugs or new features, would not normally qualify. * A new upstream version must be the best way to solve the problem. For example, if a new upstream version includes a small protocol compatibility fix and a large set of user interface changes, then, without any judgement required as to the benefits of the user interface changes, we will normally prefer to backport the protocol compatibility fix to the version currently in Ubuntu. * The upstream developers must be willing to work with Ubuntu. A responsive upstream who understands Ubuntu's requirements and is willing to work within them can make things very much easier for us. * The upstream code must be well-tested (in terms of unit and system tests). It must also be straightforward to run those tests on the actual packages proposed for deployment to Ubuntu users. * Where possible, the package must have minimal interaction with other packages in Ubuntu. Ensuring that there are no regressions in a library package that requires changes in several of its reverse-dependencies, for example, is significantly harder than ensuring that there are no regressions in a package with a straightforward standalone interface that can simply be tested in isolation. We would not normally accept the former, but might consider the latter. Once approved by the Tech Board, the exception must have a documented update policy, e.g. http://wiki.ubuntu.com/LandscapeUpdates. Based on these guidelines and the core functionality OpenStack serves in Ubuntu Cloud, the Ubuntu Server team did not feel it was in the best interest of their users, nor Ubuntu in general, to pursue an SRU exception. === What about using Ubuntu Backports? === The Ubuntu Backports process (excludes kernel) provides us a mechanism for releasing package updates for stable releases that provide new features or functionality. Changes were recently made to `apt` in Ubuntu 11.10, whereby it now only installs packages from Backports when they are explicitly requested. Prior to 11.10, `apt` would install everything from Backports once it was enabled, which led to packages being unintentionally upgraded to newer versions. The primary drawbacks with using the Backports archive is that the Ubuntu Security team does not provide updates for the archive, it’s a bit of a hassle to enable per package updates, and Canonical doesn’t traditionally offer support services for the packages hosted there. Furthermore, with each new release of OpenStack, there are other applications that OpenStack depends on that also must be at certain levels. By having more than one version of OpenStack in the same Backports archive, we run a huge risk of having backward compatibility issues with these dependencies. === How Will You Ensure Stability and Quality? === In order for us to ensure users have a safe and reliable upgrade path, we will establish a QA policy where all new versions and updated dependencies are required to pass a specific set of regression tests with a 100% success rate. In addition: * Unit testing must cover a minimum set of functionality and APIs * System test scenarios must be executed for 24, 48 and 72 hours uninterrupted. * Package testing must cover: initial installation, upgrades from the previous OpenStack release, and upgrades from the previous LTS and non-LTS Ubuntu release. * All test failures must be documented as bugs in Launchpad, with regressions marked Fix Released before the packages are allowed to exit QA. * Test results are posted publicly and announced via a mailing list specifically created for this effort only. * Only upon successfully exiting QA will packages be pushed into the Ubuntu Cloud archive. === What Happens With OpenStack Support and Maintenance in 14.04? === Good question. The cycle could repeat itself, however at this point Canonical is not making such a commitment. If the rate of innovation and growth of the OpenStack project matures to a point where users become less likely to need the next release for its improved stability and/or quality, and instead just want it for a new feature, then we would likely return to our traditional LTS maintenance and support model. |
This will ensure that bugs are raised against the [[https://launchpad.net/cloud-archive | cloud-archive]] project on Launchpad. |
The Ubuntu Cloud Archive
Canonical’s Ubuntu Cloud Archive (UCA) gives users the ability to install backported OpenStack versions on Ubuntu LTS releases.
The Ubuntu and OpenStack projects publish new releases every six months at approximately the same time. Each Ubuntu release therefore includes a new OpenStack version by default. It is this OpenStack version that is backported to the latest LTS via the UCA. The Ubuntu OpenStack release cycle graphic represents this scheme visually over time.
SRU process
The SRU process for OpenStack and the UCA is used during the development of a new UCA release and when backporting any updated dependencies and bug/security fixes to an existing UCA release.
For example, in terms of a new UCA release, Ubuntu Lunar ships with OpenStack 2023.1 Antelope by default. In this timeframe, the latest LTS is Ubuntu 22.04 (Jammy). Antelope packages (binary and source) are therefore backported to Jammy via the Antelope UCA release. In order for this to happen, individual Lunar packages are backported according to this staged process:
lunar -> antelope-staging -> antelope-proposed -> antelope-updates
When backporting fixes to an existing UCA release the original Ubuntu release must also get the update:
lunar-proposed -> antelope-staging -> antelope-proposed
When Lunar reaches end-of-life, Antelope package updates will be uploaded directly to the Antelope UCA.
This process can be monitored live with the Ubuntu Cloud Archive Tracker. It includes package versions for each of the above stages and for all UCA releases. The first column in the tracker is Ubuntu and represents the first stage in the above two scenarios.
Using the UCA
The release schedule of OpenStack and Ubuntu are generally synchronised: a new OpenStack release becomes available in the UCA every six months and coincides with each release of Ubuntu. As OpenStack releases are added to the UCA and as releases fall out of support this section will be updated.
A UCA OpenStack release is enabled on a host with the add-apt-repository command (it is recommended to run sudo apt update both before and after).
Ubuntu 24.04 LTS
On 24.04, OpenStack Dalmatian (non-SLURP) is supported for 9 months.
2024.2 Dalmatian
sudo add-apt-repository cloud-archive:dalmatian
Ubuntu 22.04 LTS
On 22.04, OpenStack Zed is supported for 18 months, OpenStack Antelope for 36 months, and OpenStack Bobcat (non-SLURP) is supported for 9 months. 24.04's default OpenStack version (Caracal) is supported in the UCA for 36 months (i.e. until the end of the Ubuntu 22.04 LTS lifecycle).
2024.1 Caracal
sudo add-apt-repository cloud-archive:caracal
2023.2 Bobcat
sudo add-apt-repository cloud-archive:bobcat
2023.1 Antelope
sudo add-apt-repository cloud-archive:antelope
Zed
sudo add-apt-repository cloud-archive:zed
Ubuntu 20.04 LTS
On 20.04, OpenStack Victoria and OpenStack Xena are supported for 18 months each, and OpenStack Wallaby for 36 months. 22.04's default OpenStack version (Yoga) is supported in the UCA for 36 months (i.e. until the end of the Ubuntu 20.04 LTS lifecycle).
Yoga
sudo add-apt-repository cloud-archive:yoga
Xena
sudo add-apt-repository cloud-archive:xena
Wallaby
sudo add-apt-repository cloud-archive:wallaby
Ubuntu 18.04 LTS
On 18.04, OpenStack Rocky and OpenStack Train are supported for 18 months each, and OpenStack Stein for 36 months. OpenStack Ussuri, 20.04's default OpenStack version, is supported in the UCA for 36 months (i.e. until the end of the Ubuntu 18.04 LTS lifecycle).
Ussuri
sudo add-apt-repository cloud-archive:ussuri
Ceph and the UCA
The below table shows the relationship between UCA release, Ceph release, Ubuntu LTS release, and Ubuntu default archive ("distro").
Ceph release |
Default archive |
UCA release |
Ubuntu LTS release |
Squid |
yes |
- |
Noble |
Squid |
- |
jammy-caracal |
Jammy |
Reef |
- |
jammy-bobcat |
Jammy |
Quincy |
yes |
- |
Jammy |
Quincy |
- |
focal-yoga |
Focal |
Pacific |
- |
focal-xena |
Focal |
Pacific |
- |
focal-wallaby |
Focal |
Octopus |
yes |
- |
Focal |
Octopus |
- |
bionic-ussuri |
Bionic |
Nautilus |
- |
bionic-train |
Bionic |
Mimic |
- |
bionic-stein |
Bionic |
Mimic |
- |
bionic-rocky |
Bionic |
Luminous |
yes |
- |
Bionic |
Luminous |
- |
xenial-queens |
Xenial |
Jewel |
yes |
- |
Xenial |
Jewel |
- |
trusty-mitaka |
Trusty |
Firefly |
yes |
- |
Trusty |
Reporting a bug
To report bugs against packages from the UCA, please use the ubuntu-bug tool.
For example:
ubuntu-bug nova-compute
This will ensure that bugs are raised against the cloud-archive project on Launchpad.
OpenStack/CloudArchive (last edited 2025-03-27 08:08:22 by gboutry)