On 04/03/2018 10:56 AM, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt,
which in turn makes it easier to decide when a platform / software
version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/index.html.in | 2 +-
docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 docs/platforms.html.in
diff --git a/docs/index.html.in b/docs/index.html.in
index 1b3a7a3db6..4783c39e3c 100644
--- a/docs/index.html.in
+++ b/docs/index.html.in
@@ -28,7 +28,7 @@
The libvirt project:
</p>
<ul>
- <li>is a toolkit to manage virtualization hosts</li>
+ <li>is a toolkit to manage <a
href="platforms.html.in">virtualization platforms</a></li>
<li>is accessible from C, Python, Perl, Java and more</li>
<li>is licensed under open source licenses</li>
<li>supports <a href="drvqemu.html">KVM</a>,
diff --git a/docs/platforms.html.in b/docs/platforms.html.in
new file mode 100644
index 0000000000..859b482428
--- /dev/null
+++ b/docs/platforms.html.in
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html>
+<html
xmlns="http://www.w3.org/1999/xhtml">
+ <body>
+ <h1>Supported host platforms</h1>
+
+ <ul id="toc"></ul>
+
+ <h2>Build targets</h2>
+> + <p>
+ Libvirt drivers aim to support building and executing on multiple
+ host OS platforms. This document outlines which platforms are the
+ major build targets. These platforms are used as the basis for deciding
+ upon the minimum required versions of 3rd party software libvirt depends
+ on. If a platform is no listed here, it does not imply that libvirt
+ won't work. If an unlisted platform has comparable software versions
+ to a listed platform, there is every expectation that it will work.
+ Bug reports are welcome for problems encountered on unlisted platforms
+ unless they are clearly older vintage that what is described here.
+ </p>
+
+ <h3>Linux OS</h3>
+
+ <p>
+ For distributions with frequent, short-lifetime releases (Fedora,
+ Ubuntu, OpenSUSE, etc), the project will aim to support all versions
+ that are not end of life by their respective vendors.
+ </p>
+
+ <p>
+ For distributions with long-lifetime releases (RHEL, Ubuntu LTS,
+ SLES, etc), the project will aim to support the most recent major
+ version at all times. Support for the previous major version will
+ be dropped 2 years after the new major version is released.
+ </p>
+
+ <h3>Windows</h3>
+
+ <p>
+ The project supports building with current versions of the MinGW
+ toolchain, hosted on Linux.
+ </p>
+
+ <h3>OS-X</h3>
+
+ <p>
+ The project supports building with the current version of OS-X,
+ with the current homebrew package set available.
+ </p>
+
+ <h3>FreeBSD</h3>
+
+ <p>
+ The project will aim to support the most recent major version
+ at all times. Support for the previous major version will
+ be dropped 2 years after the new major version is released.
+ </p>
+
Could we add some sort of table where we could keep track of "known" and
supported OS versions, what libvirt version was used, what QEMU version
was used?
<table class="top_table">
<tr>
<th> OS Release </th>
<th> QEMU Version </th>
<th> libvirt Version </th>
</tr>
</table>
I'm sure Red Hat folks could easily list the Fedora, RHEL, and CentOS
versions... Probably need a few others to provide feedback on their
particular host platform of choice.
Once created it is a periodic maintenance task.
+ <h2>Virtualization platforms</h2>
+
+ <p>
+ For hypervisor drivers which execute locally (QEMU, LXC, VZ,
Probably could add a link to
https://libvirt.org/drivers.html for
"hypervisor drivers"
+ libxl, etc), the set of supported operating system platforms
+ listed above will inform choices as to the minimum required
+ versions of 3rd party libraries and hypervisor management APIs.
The following feels like a new paragraph....
+ If a hypervisor is not commonly shipped directly by any
distro
+ listed above, (VMWare ESX, HyperV, VZ), the project aims to
+ support versions upto 5 years, or until the vendor discontinues
up to
+ support, whichever comes first.
+ </p>
Again a table may be interesting here especially for those older ones
that Martin noted without any change for quite a few years now. Possibly
calls out that we need to perform a retirement ritual on some thing[s].
Perhaps a separate table listing when specific driver or a specific
driver version support was removed from upstream. Essentially an easy
way for someone to find it on some older branch.
For these the table formats aren't as clear, but hypervisor drivers
could have multiple row entries - one for each target OS platform.
Something to make referencing history easier.
John
+
+ </body>
+</html>