openstack
/
charm-guide
Code Issues Proposed changes

Move OVN details from release notes to appendix 

Depends-On: I36628120a48333d77b64634394962846ecfa221f
Change-Id: I748e46f5a323c138537d25e15fe74bee89d49875
This commit is contained in:
Frode Nordahl 2020-02-06 14:09:21 +01:00
parent 3b30ec847d
commit 5e23e13ebb
No known key found for this signature in database
GPG Key ID: 6A5D59A3BA48373F
1 changed files with 0 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
doc/source/2002.rst
View File

@ -197,60 +197,9 @@ The 20.02 OpenStack Charms release updates the tech preview suite of charms
that allows you to model Open Virtual Network (OVN). OVN provides open source
network virtualization for Open vSwitch (OVS).
One of the main drivers for this enablement work is the prospect of being able
to hardware-offload everything. This is possible due to how OVN programs
everything in Open vSwitch with OpenFlow rules. This in turn provides a
uniform way of programming the hardware forwarding tables of supported NICs.
Hardware-offloading is a prerequisite for effective handling of workloads with
high bandwidth consumption.
OVN also provides a more flexible way of configuring external Layer3 networking
as OVN does not require every node (``Chassis`` in OVN terminology) in a
deployment to have direct external connectivity. This plays nicely with
Layer3-only datacenter fabrics (RFC 7938).
East/West traffic is distributed by default. North/South traffic is highly
available by default. Liveness detection is done using the Bidirectional
Forwarding Detection (BFD) protocol.
Please refer to appendix `Open Virtual Network (OVN)`_ in the `OpenStack Charms
Deployment Guide`_ for more details.
Known feature gaps at this point in time:
* No validation has been done with DPDK, SR-IOV or hardware-offloading in the
charms.
* Support for the Octavia OVN provider driver has not been implemented in the
charms and no validation has been done with LBaaS in general.
* Only limited validation has been done with other Neutron extensions, and it
may be possible to configure unsupported combinations of features with
undefined results.
* There is an unresolved issue with security groups rules that reference
remote security groups. Please remove any such rules while testing.
Example of how you could reset your default security group rules:
.. code:: bash
PROJECT_ID=$(openstack project list -f value -c ID \
--domain admin_domain)
SECGRP_ID=$(openstack security group list --project $PROJECT_ID \
| awk '/default/{print$2}')
openstack security group rule delete \
$(openstack security group rule list $SECGRP_ID| awk '/IPv./{print$2}')
openstack security group rule create --egress --protocol any \
--ethertype IPv4 $SECGRP_ID
openstack security group rule create --egress --protocol any \
--ethertype IPv6 $SECGRP_ID
openstack security group rule create --ingress --protocol any \
--ethertype IPv4 $SECGRP_ID --remote-ip YOUR_IPV4_LAB_NETWORK_CIDR
openstack security group rule create --ingress --protocol any \
--ethertype IPv6 $SECGRP_ID --remote-ip YOUR_IPV6_LAB_NETWORK_CIDR
Swift Global Replication
~~~~~~~~~~~~~~~~~~~~~~~~