openstack/os-vif
Code Issues Proposed changes

Reflow docs to 79 columns

Browse Source 
* This whitespace-only patch reflows the docs (mostly) to 79 columns,
  except for unbreakable links.
* The glossary also had a missing newline at the end of the file.

Change-Id: I8a6c741555de5ed62990fbb2c034651f73327784
Signed-off-by: Jan Gutter <jan.gutter@netronome.com>
This commit is contained in:
Jan Gutter 2018-10-11 16:35:31 +02:00
parent 409455d16c
commit 8606af13c7
5 changed files with 46 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
HACKING.rst
View File

@ -1,4 +1,5 @@
os_vif Style Commandments
=========================
Read the OpenStack Style Commandments https://docs.openstack.org/hacking/latest/
Read the OpenStack Style Commandments
https://docs.openstack.org/hacking/latest/

2
doc/source/reference/glossary.rst
View File

@ -207,4 +207,4 @@ Glossary
Refer to this `article by Scott Lowe`__ for more information.
__ http://blog.scottlowe.org/2009/12/02/what-is-sr-iov/
__ http://blog.scottlowe.org/2009/12/02/what-is-sr-iov/

86
doc/source/user/host-info.rst
View File

@ -2,75 +2,63 @@
Host Information
================
To enable negotiation of features between a service host
(typically a compute node) and the network provider host,
os-vif exposes some objects that describe the host running
the plugins.
To enable negotiation of features between a service host (typically a compute
node) and the network provider host, os-vif exposes some objects that describe
the host running the plugins.
Host Information Objects
========================
The following objects encode the information about the
service host.
The following objects encode the information about the service host.
HostInfo
--------
This class provides information about the host as a whole.
This currently means a list of plugins installed on the
host. In the future this may include further information
about the host OS state.
This class provides information about the host as a whole. This currently means
a list of plugins installed on the host. In the future this may include further
information about the host OS state.
HostPluginInfo
--------------
This class provides information about the capabilities of
a single os-vif plugin implementation that is installed
on the host. This currently means a list of VIF objects
that the plugin is capable of consuming. In the future
this may include further information about resources on
the host that the plugin can/will utilize. While many
plugins will only ever support a single VIF object, it
is permitted to support multiple different VIF objects.
An example would be openvswitch which can use the same
underlying host network functionality to configure a VM
in several different ways.
This class provides information about the capabilities of a single os-vif
plugin implementation that is installed on the host. This currently means a
list of VIF objects that the plugin is capable of consuming. In the future this
may include further information about resources on the host that the plugin
can/will utilize. While many plugins will only ever support a single VIF
object, it is permitted to support multiple different VIF objects. An example
would be openvswitch which can use the same underlying host network
functionality to configure a VM in several different ways.
HostVIFInfo
-----------
This class provides information on a single VIF object that
is supported by a plugin. This will include the versioned
object name and the minimum and maximum versions of the
object that can be consumed.
It is the responsibility of the network provider to ensure
that it only sends back a serialized VIF object that satisfies
the minimum and maximum version constraints indicated by the
plugin. Objects outside of this version range will be rejected
with a fatal error.
This class provides information on a single VIF object that is supported by a
plugin. This will include the versioned object name and the minimum and maximum
versions of the object that can be consumed.
It is the responsibility of the network provider to ensure that it only sends
back a serialized VIF object that satisfies the minimum and maximum version
constraints indicated by the plugin. Objects outside of this version range will
be rejected with a fatal error.
Negotiating networking
======================
When a service host wants to create a network port, it will
first populate an instance of the HostInfo class, to describe
all the plugins installed on the host. It will then serialize
this class to JSON and send it to the network manager host.
The network manager host will deserialize it back into a
HostInfo object. This can then be passed down into the network
driver which can use it to decide how to configure the network
port.
When a service host wants to create a network port, it will first populate an
instance of the HostInfo class, to describe all the plugins installed on the
host. It will then serialize this class to JSON and send it to the network
manager host. The network manager host will deserialize it back into a HostInfo
object. This can then be passed down into the network driver which can use it
to decide how to configure the network port.
If the os-vif version installed on the network host is older
than that on the service host, it may not be able to deserialize
the HostInfo class. In this case it should reply with an error
to the service host. The error message should report the maximum
version of the HostInfo class that is supported. the service
host should then backlevel its HostInfo object to that version
before serializing it and re-trying the port creation request.
If the os-vif version installed on the network host is older than that on the
service host, it may not be able to deserialize the HostInfo class. In this
case it should reply with an error to the service host. The error message
should report the maximum version of the HostInfo class that is supported. the
service host should then backlevel its HostInfo object to that version before
serializing it and re-trying the port creation request.
The mechanism or transport for passing the plugin information
between the network and service hosts is left undefined. It is
upto the user of os-vif to decide upon the appropriate approach.
The mechanism or transport for passing the plugin information between the
network and service hosts is left undefined. It is upto the user of os-vif to
decide upon the appropriate approach.

4
doc/source/user/plugins/linux-bridge.rst
View File

@ -3,8 +3,8 @@ Linux Bridge
============
The Linux Bridge plugin, ``vif_plug_linux_bridge``, is an *os-vif* VIF plugin
for the Linux Bridge network backend. It is one of three plugins provided as part
of *os-vif* itself, the others being :doc:`ovs` and :doc:`noop`.
for the Linux Bridge network backend. It is one of three plugins provided as
part of *os-vif* itself, the others being :doc:`ovs` and :doc:`noop`.
Supported VIF Types
-------------------

7
doc/source/user/vif-types.rst
View File

@ -73,7 +73,8 @@ VIFHostDevice
-------------
This class provides a way to pass a physical device to the guest. Either an
entire physical device, or an SR-IOV PCI device virtual function, are permitted.
entire physical device, or an SR-IOV PCI device virtual function, are
permitted.
.. _vif-nesteddpdk:
@ -116,8 +117,8 @@ device supporting the :term:`802.1Qbh` spec.
VIFPortProfileFPOpenVSwitch
---------------------------
This profile provides the metadata required to associate a fast path :term:`vhost-user`
VIF with an :term:`Open vSwitch` port.
This profile provides the metadata required to associate a fast path
:term:`vhost-user` VIF with an :term:`Open vSwitch` port.
VIFPortProfileOVSRepresentor
----------------------------