Until know, for scale issues, the creation of some NSX backend resources
for loadbalancing was postpone until the first member creation.
This complicates the code unnecessarily, since the scale issues were
already resolved.
The new code will create the matching backend objects for each
LBaaS/Octavia object upon creation.
In case external vip loadbalancer - the service will be created without an attachement,
which will be added upon member creation.
In addition a DB migration is added to mark as ERROR old incomplete load
balancers.
Depends-on: Ic4e604883a7b1437af995110d2d684c0bd396a52
Change-Id: Ib478c336840c2e441bbaeffe94700a5e267c6bef
Until know, for scale issues, the creation of some NSX backend resources
for loadbalancing was postpone until the first member creation.
This complicates the code unnecessarily, since the scale issues were already resolved.
The new code will create the matching backend objects for each LBaaS/Octavia object upon creation.
In addition a DB migration is added to mark as ERROR old incomlete load balancers.
Change-Id: I2d1b9046a262fb43fd4b05e378dcf00f7f80adc0
This patch adds a driver for FWaaS V2 support in the NSX-V plugin.
It supports setting firewall rules per router interface port on the router
edge firewall.
In addition, the FWaaS TVD driver will now support NSX-V as well.
The driver code is a combination of the NSX-V3 FWaas-V2 code, and the old
NSX-V FWaaS-V1 code that is being deleted.
Change-Id: Iacc7eaff0c70b68156516008cf0277c154edd76b
Implementing the Octavia support for NSX-V & NSX-T.
Follow up patches will handle the TVD plugin, Status updates,
and migration.
Since Octavia is not (yet?) in the requirements, using a hack to allow unittests
to be skipped.
Co-Authored-by: Adit Sarfaty <asarfaty@vmware.com>
Change-Id: Iadb24e7eadcab658faf3e646cc528c2a8a6976e5
The nsx-v3 plugin can add default Tier-0 router configuration per
availability zone. The Tier-0 rotuer will be used as a default for
external networks creation in this AZ.
Change-Id: I18e917a6b3deb40429626f7f0018e5da7ab72a8b
NSX|V3: This feature will enable an admin user to configure a range
of VLAN IDs per VLAN Transport Zone, so when they create a VLAN,
the VLAN tag will be set accordingly.
The configuration is being done in the nsx.ini file, under the relevant
section for nsx-v3, the admin will note the tz-id, with either a
predefined range(s) (min/max values) or only the transport zone itself
(which means that any value can be chosen).
The admin user will create the network noting “provider:physical_network”,
if they select a VLAN ID, than it will be used, if not - one will be
chosen according to the configuration mentioned above.
New configuration variable in nsx.ini under nsx_v3: network_vlan_ranges
network_vlan_ranges=<TZ_UUID>:<min_val>:<max_val>
Change-Id: Id202ca28bda44286deacb5c9969ffd92aa564a90
Signed-off-by: Michal Kelner Mishali <mkelnermishal@vmware.com>
Traffic to ports that have port security and port security enabled
will by default be discarded. A configuration variable has been added
with default False so that there is not a degradation with the current
behaviour.
The variable is use_default_block_all.
Change-Id: I5569234de01c116d1ad3161cfaf54404467f6816
Enable admin to control if ENS networks can be used.
In nsx_v3 section a new flag ens_support is added.
Change-Id: I99b885072964870fe61a26a5bab71c7ed0790c87
New support for VPNaaS on NSX-V3 2.2
Creating a vpn service per neutron service,
and ike/ipsec/dpd policies + endpoints + connection per neutron connection
Change-Id: Iad3778c1d826ae67f1b602625f5be0fe2f4c8fe3
Leverage the NSX networks support for transparent VLANS.
NOTE that the feature needs the configuration variable
cfg.CONF.vlan_transparent to be set to True.
(this is in the neutron configuration file)
This is currently only supported with overlay backing networks.
This is supported from NSX 2.2 onwards.
Change-Id: I4195a4fade42f798689ef19e6d6b59209547beaa
One can enable DNS integration for the upstream neutron
DNS integration extension by setting:
nsx_extension_drivers = vmware_dvs_dns
Closes-Bug: #1727626
Change-Id: If776d21679acfa2abf8018a8f6f19b58be24cb4b
FWaaS V2 support in NSX-v3.
Support different firewall group per router interface port for
igress/egress.
limitation: cannot support egress rules with source ip, or ingress
rules with destination ips.
Depends-on: I2a37be5518bfc8124ffca2ab05f684d8c1c3d673
Change-Id: I3ed70fa48d078bed15f30e855b73bdfb11d11c6e
Support DHCP relay by configuring the relay service per
network availability zone, or globally.
When a router interface port is created, the relay service
will be added to it.
DHCP traffic on the subnet will go through the DHCP server
configured in the dhcp relay service on the NSX, if it is
connected to the router.
Also add admin utility to update exsiting router ports when the
dhcp relay configuration changes.
A future patch will take care of firewall rules allowint the dhcp traffic.
Change-Id: I626b3377e71c269600a47b3bd805eed9d58bad82
- Deprecate the "vxlan" type
- Add the "geneve" type: with overlay transport zone
- Add the "nsx-net" type: attach an existing nsx logical switch
(vlan or overlay) to a neutron network.
In addition, this patch adds unit tests to all provider networks types.
Change-Id: I48a35c913c08ea4afcca64ed2e13db41260b95a3
New configuration option is added to the nsx-v3 plugin: switching_profiles.
It will contain a list of switching profiles uuids that will be added to
NSX ports created by neutron.
The configuration is global or per availability zone.
In case the port should contain a different profile of some type,
the port-specific profile will be used, since the backend takes the last
one of each type.
Change-Id: Ifa1dba2250b224201e6f81816feb536a35b642a5
New configuration option for the transport zones, tier0 router, dhcp
profile and md-proxy in the nsx ini file.
If init_objects_by_tags is True, the user should add a tag with a scope
(whose name will be set in search_objects_by_tags) to the overlay
transportzone, vlan transportzone and tier0 router on the nsx.
In the nsx ini file the user should configure the value of this tag for
each object instead of the object name or uuid.
Example:
[nsx_v3]
init_objects_by_tags = True
search_objects_scope = ini-scope
default_overlay_tz = ini-tag-tz
default_vlan_tz = ini-tag-tz2
default_tier0_router = ini-tag-rtr
metadata_proxy = ini-tag-md
dhcp_profile = ini-tag-dhcp
Depends-on: If05390d3b58b84290e1f306f03c5ba3654bd1fad
Change-Id: Icb66f42939e41eb32c8485f80f4e5d24cf172023
Starting newton we added support for native DHCP and metadata
provided by NSX. Since now most of the NSXv3 deployment are using
native DHCP/Metadata, default this option to True.
Change-Id: Id16fb64d898a46016f1e8e929a914d347b659458
The nsx-v FWaaS driver will add the configured firewall rules to
the router edges.
Currently there is not support for shared routers.
The rules will be edded after the current rules (NAT, LBaaS, external traffic)
for exclusive routers edges and distributed routers PLR edged.
Change-Id: I82ba90070ef4e739a0b5c4463ef03a807e26adfb
Via the configuration variable exclusive_dhcp_edge enable a tenant
to create a exclusive DHCP edge. This can be global or via AZ.
DocImpact
Change-Id: Ia5220302114d73fa89b3f3ea86141cb3208fe885
Supporting L7 policies and rules in LBAAS-v2
Including a new db table nsxv_lbaas_l7policy_bindings
for mapping between the lbaas policy ID and the nsx application rules.
Depends-on: I3b14d107dbe0a72a6e24239f06bd6c3ac597cfbb
Change-Id: Ic760be8956cea00b972b5f11f6acff294630892d
Support randomly selecting which will be the primary datastore and which
will be the secondary one when deplying an edge, in order to balance the
load.
This new option is available globally as well as per availability_zone
via a new configuration parameter edge_placement_random which will be
False by default.
Change-Id: I5bf8f8999100c4c6da4645bda6e74165575c3818
One can enable DNS integration for the upstream neutron
DNS integration extension by setting:
nsx_extension_drivers = vmware_nsxv_dns (for NSXV)
nsx_extension_drivers = vmware_nsxv3_dns (for NSXV3)
Change-Id: Id100f8034e602d92310d22f900c48d9dfbe59a8d
A new configuration variable nsx_extension_drivers
has been added. This is in the DEFAULT section. This enable us
to code support to add via configurations extensions, for
example dns_integration.
Co-authored-by: Shih-Hao Li <shihli@vmware.com>
Change-Id: Iea4715522d9c7cf327b7f1a751b78f14d5e06e75
The NSX-V3 plugin will use the NSX-V3 backend IPAM.
An IP pool will be created for each subnet, and port IPs will be allocated
from this pool.
The current backend limitation is that we cannot allocate a specific IP,
so port create/update with fixed_ips will fail, unless the requested ip
is the subnet gateway ip.
To enable this option set 'ipam_driver = vmware_nsxv3_ipam' in the
neutron.conf
Change-Id: I5263555cbb776018a5d01f19d0997fd2adf6483d
Enable a admin to configure a global search domain. That is, if a
subnet is not created with a search domain (commit
d9f3ee826acf3fc5a1c436361790940237ef9784) then is a domain is
defined in the configuration file then we can use that one.
In the nsxv section there will be a new variable
- dns_search_domain
Change-Id: I112a00dbc89b1c7702e82ecfa6ec974b7b9cce8d
Support configuration of name or uuid (instead of only uuid) for
2 nsx_v3 parameters: dhcp_profile, metadata_proxy.
Assert on init if the uuid or name was no found on the backend,
or if the name is not unique.
Change-Id: Ife6263b7cf1759a2fc309205552eb79138d512a1
In case of multiple NSX managers in the nsx_api_managers configuration,
it is now possible to configure a different username/password/ca_file for each
of the managers.
The nsxv3 configuration parameters ca_file, nsx_api_user & nsx_api_password are
now lists.
If they contain only 1 value, it will be used for all the managers.
Else, the order of of the values is expected to match the order of the
nsx_api_managers.
Change-Id: I31b955c9ee449126acde96de48a1887b94c38e29
This patch adds support for trunk extensions in the NSXv3
plugin.
Now you can create trunk and subports which map to CIF
on the backend.
i.e. trunk port <-> parent port and subport <-> child port
on the backend.
If backend fails to update subports, the status of trunk will be set
to ERROR.
Use OSC commands for trunk CRUD operations.
For e.g.
Create trunk with a subport:
openstack network trunk create --parent-port <parent-port>
--subport port=child-port,segmentation-type=vlan,segmentation-id=200
TRUNK_NAME
Delete trunk:
openstack network trunk delete TRUNK_NAME
Change-Id: Iedd47d868d803ca8c52856554885fd7d14668924
Support configuration of name or uuid (instead of only uuid) for 4 nsx_v3
parameters: default_overlay_tz, default_vlan_tz, default_bridge_cluster
and default_tier0_router.
Assert on init if the uuid or name was no found on the backend, or if the
name is not unique.
DocImpact: Configuration options default_overlay_tz_uuid, default_vlan_tz_uuid,
default_bridge_cluster_uuid and default_tier0_router_uuid were
replaced with default_overlay_tz, default_vlan_tz, default_bridge_cluster
and default_tier0_router and support name or uuid now.
Change-Id: Id153d4d69165b161c04c403b578657c51af20e9c
Release management team has modified the way it releases
projects and a new process and guideline has been established.
This change adds support for the same. More information on
this can be found at [1].
Within OpenStack, reno can be used to create release notes
using the following command:
tox -e venv -- reno new slug-goes-here
where slug-goes-here is a prefix to your notes.
More info on reno usage can be found at [2].
[1]: http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html
[2]: http://docs.openstack.org/developer/reno/usage.html
Change-Id: Ic4c1d246b0c9dda7c4c3901ed9527481b6f8f3e3