[libvirt] Update on the goal page, patch and discussion

[Eric Blake]

On 03/24/2011 04:40 AM, Daniel Veillard wrote:
>  It is a patch but beyond the unevitable spelling errors it contains
> I would appreciate some feedback on the content, which also defines the
> limits of the project.
> 
>  Some significant things to note in the diff below:
>    - we do extend libvirt scope beyond purely managing domains, there is
>      already a number of blocks which are here as helpr functions to
>      manage the resources on the host.
>    - we are expanding in the direction of libvirt being sufficient to do
>      most of the management on the Host (but within the limits of the need
>      for virtualization, e.g. managing users on the host is out of scope)
>    - we don't require anymore APIs to be supported by multiple
>      hypervisors to get in, it's already the case in practice, but we
>      should still make sure the semantic of those APIs are clear. We
>      added quite a bit for QEmu, but for example I saw on IRC that VBox
>      could emulate a network unplug/replug on a domain interface, and
>      that would be a good addition even if a priori no other hypervisor
>      supports it.
>    - Make clear that all libvirt APIs are available remotely, which is
>      key to use libvirt for building management tools.
>    - link the goal page from the project main page
> 
> As for libvirt project directions, I think it just reflects the natural
> evolution in the last couple of years. We are less hypervisor agnostic
> and extending in the Host management. Clearly there is interest in
> making sure libvirt is complete in term of features for the hypervisors
> supported, especially the ones like KVM or LXC which don't really have
> integrated management library.
> 
> Maybe I should have added a bit more about the security aspect, as
> integration of security context and making sure remote access are
> secured are very important additions to the library.
> 
>  Wording and content comments welcome, I guess we are all agreeing
> but the goals of the project as written are certainly up for discussion :-)
> 
> Daniel
> 
> diff --git a/docs/goals.html.in b/docs/goals.html.in
> index 8f0d075..6394709 100644
> --- a/docs/goals.html.in
> +++ b/docs/goals.html.in
> @@ -16,20 +16,32 @@
>      <p class="image">
>        <img alt="Hypervisor and domains running on a node" src="node.gif"/>
>      </p>
> -    <p>Now we can define the goal of libvirt: to provide a common generic
> -    and stable layer to securely manage domains on a node. The node may be
> -    distant and libvirt should provide all APIs needed to provision, create,
> -    modify, monitor, control, migrate and stop the domains, within the limits
> -    of the support of the hypervisor for those operations. Multiple nodes may
> -    be accessed with libvirt simultaneously but the APIs are limited to
> -    single node operations.</p>
> +    <p>Now we can define the goal of libvirt: <b> to provide a common and
> +    stable layer sufficient to securely manage domains on a node, possibly
> +    distant</b>.</p>

I think 'possibly remote' reads better than 'possibly distant'.

> +    <p> As a result, libvirt should provide all APIs needed to do the
> +    management like: provision, create, modify, monitor, control, migrate

s/management like/management, such as/

> +    and stop the domains - within the limits of the support of the hypervisor
> +    for those operations. Some operations which may be hypervisor specific,
> +    if needed for domain management should be provided too.

Yes, it makes sense to document that we don't mind providing
well-documented hypervisor-specific operations.  But the wording might
sound better as:

Not all hypervisors provide the same operations; but if an operation is
useful for domain management of even one specific hypervisor it is worth
providing in libvirt.

> Multiple nodes
> +    may be accessed with libvirt simultaneously but the APIs are limited to

s/ but/, but/

> +    single node operations. Node ressource operations which are needed

s/ressource/resource/

> +    for the management and provisioning of domains are also in the scope of
> +    the libvirt API, like interface setup, firewall rules, storage management
> +    and in general provisioning APIs.

s/like/such as/
s/and in general/and general/

> Libvirt will also provide the state
> +    monitoring APIs needed to implement management policies, obviously
> +    checking domain state but also expose local node resources consumption.

s/expose local node resources/exposing local node resource/

>      <p>This implies the following sub-goals:</p>
>      <ul>
> -      <li>the API should not be targeted to a single virtualization environment
> -    which also means that some very specific capabilities which are not generic
> -    enough may not be provided as libvirt APIs</li>
> +      <li>All API can be carried remotely though secure APIs</li>
> +      <li>While most API will be generic in term of hypervisor or Host OS,
> +    some API may be targeted to a single virtualization environment
> +    as long as the semantic for the operations from a domain management
> +    perspective is clear</li>

I agree with this change.

>        <li>the API should allow to do efficiently and cleanly all the operations
> -    needed to manage domains on a node</li>
> +    needed to manage domains on a node including resource provisioning and
> +    setup</li>

s/node including/node, including/

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110325/a8c78d60/attachment-0001.sig>