[libvirt PATCH 2/2] kbase: Reorder deployments

Andrea Bolognani posted 2 patches 3 years, 1 month ago
[libvirt PATCH 2/2] kbase: Reorder deployments
Posted by Andrea Bolognani 3 years, 1 month ago
List the various options so that the most likely ones come
first.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
 docs/kbase/rpm-deployment.rst | 52 +++++++++++++++++------------------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst
index d1180fb0c3..31805c2280 100644
--- a/docs/kbase/rpm-deployment.rst
+++ b/docs/kbase/rpm-deployment.rst
@@ -23,32 +23,6 @@ listed on this page will exist.
 Deployment choices
 ==================
 
-Client only install
--------------------
-
-If an application is capable of using multiple different virtualization drivers
-it is undesirable to force the installation of a specific set of drivers. In
-this case the application will merely wish to request a client only install
-
-Alternatively if an application is intended to communicate with a hypervisor on
-a remote host there is no need to install drivers locally, only a client is
-needed
-
-The only required package is the `libvirt-libs`, however, it is useful to
-also install `libvirt-client`.
-
-
-Every possible virt driver
---------------------------
-
-There is rarely a need to install every virt driver at once on a given host.
-In the unlikely event that this is needed, however, the `libvirt` package
-should be installed.
-
-Note that this doesn't actually pull in the hypervisors, only the libvirt
-code to talk to the hypervisors.
-
-
 Full features for one virt driver
 ---------------------------------
 
@@ -65,6 +39,21 @@ footprint of the daemons is also relatively large since a lot of code is
 loaded.
 
 
+Client only install
+-------------------
+
+If an application is capable of using multiple different virtualization drivers
+it is undesirable to force the installation of a specific set of drivers. In
+this case the application will merely wish to request a client only install
+
+Alternatively if an application is intended to communicate with a hypervisor on
+a remote host there is no need to install drivers locally, only a client is
+needed
+
+The only required package is the `libvirt-libs`, however, it is useful to
+also install `libvirt-client`.
+
+
 Minimal features for one virt driver
 ------------------------------------
 
@@ -87,6 +76,17 @@ and host devices, leaving only the bare minimum functionality for managing
 KVM guests.
 
 
+Every possible virt driver
+--------------------------
+
+There is rarely a need to install every virt driver at once on a given host.
+In the unlikely event that this is needed, however, the `libvirt` package
+should be installed.
+
+Note that this doesn't actually pull in the hypervisors, only the libvirt
+code to talk to the hypervisors.
+
+
 RPM packages
 ============
 
-- 
2.38.1
Re: [libvirt PATCH 2/2] kbase: Reorder deployments
Posted by Jim Fehlig 3 years, 1 month ago
On 12/14/22 11:39, Andrea Bolognani wrote:
> List the various options so that the most likely ones come
> first.
> 
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
>   docs/kbase/rpm-deployment.rst | 52 +++++++++++++++++------------------
>   1 file changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst
> index d1180fb0c3..31805c2280 100644
> --- a/docs/kbase/rpm-deployment.rst
> +++ b/docs/kbase/rpm-deployment.rst
> @@ -23,32 +23,6 @@ listed on this page will exist.
>   Deployment choices
>   ==================
>   
> -Client only install
> --------------------
> -
> -If an application is capable of using multiple different virtualization drivers
> -it is undesirable to force the installation of a specific set of drivers. In
> -this case the application will merely wish to request a client only install
> -
> -Alternatively if an application is intended to communicate with a hypervisor on
> -a remote host there is no need to install drivers locally, only a client is
> -needed
> -
> -The only required package is the `libvirt-libs`, however, it is useful to
> -also install `libvirt-client`.
> -
> -
> -Every possible virt driver
> ---------------------------
> -
> -There is rarely a need to install every virt driver at once on a given host.
> -In the unlikely event that this is needed, however, the `libvirt` package
> -should be installed.
> -
> -Note that this doesn't actually pull in the hypervisors, only the libvirt
> -code to talk to the hypervisors.
> -
> -
>   Full features for one virt driver
>   ---------------------------------
>   
> @@ -65,6 +39,21 @@ footprint of the daemons is also relatively large since a lot of code is
>   loaded.
>   
>   
> +Client only install
> +-------------------
> +
> +If an application is capable of using multiple different virtualization drivers
> +it is undesirable to force the installation of a specific set of drivers. In
> +this case the application will merely wish to request a client only install
> +
> +Alternatively if an application is intended to communicate with a hypervisor on
> +a remote host there is no need to install drivers locally, only a client is
> +needed
> +
> +The only required package is the `libvirt-libs`, however, it is useful to
> +also install `libvirt-client`.
> +
> +

IMO, these days the "Minimal features for one virt driver" is as likely or more 
so than client-only. But you can choose the color of the shed :-).

Reviewed-by: Jim Fehlig <jfehlig@suse.com>

Regards,
Jim

>   Minimal features for one virt driver
>   ------------------------------------
>   
> @@ -87,6 +76,17 @@ and host devices, leaving only the bare minimum functionality for managing
>   KVM guests.
>   
>   
> +Every possible virt driver
> +--------------------------
> +
> +There is rarely a need to install every virt driver at once on a given host.
> +In the unlikely event that this is needed, however, the `libvirt` package
> +should be installed.
> +
> +Note that this doesn't actually pull in the hypervisors, only the libvirt
> +code to talk to the hypervisors.
> +
> +
>   RPM packages
>   ============
>