MidoNet v5.0
Midonet uses Zookeeper for its topology store. While Zookeeper has some advantages over relational database systems, a major drawback is the lack of referential integrity enforcement and secondary indices. For example, a SQL schema can be designed such that when a router is deleted, all of its ports are automatically deleted, or alternatively that attempts to delete a router will fail as long as the router has ports. Zookeeper is agnostic with respect to the contents of its data nodes, and thus provides no built-in way to do this, or even to find out what ports a router has, short of scanning all the ports.
In 1.X, we worked around this limitation by a system of explicit two-way references. When creating a router port, for example, we would find the router indicated by the port's routerId property and add the port's ID to the router's portIds property. When deleting the port, we would again find the router indicated by the port's routerId field and remove the port's ID from the router's portIds property. When deleting the router, we would check to see if its portIds list was empty. If so, we would allow the deletion to proceed, but if not we would return an error stating the router could not be deleted because it had one or more ports.
All of this was enforced via manually coding these behaviors on a case-by-case basis, which was both tedious and error-prone. Starting in Midonet 5.0, the topology store is maintained by the ZookeeperObjectMapper (ZOOM), a component of the Midonet Cluster that automates the maintenance of these two-way references and enforcement of certain rules, such as:
- When creating or updating an object such that it contains a reference to another object, the other object must exist.
- One-to-one or one-to-many relationships must be respected. For example, a router may have many ports, but a port can belong to only one router.
- Two objects of the same type and same ID may not exist.
The details of the relationships between particular objects are specified declaratively, making the enforcement of these relationships easier and much less error-prone than in Midonet 1.X.
midonet-api package has been replaced with midonet-cluster.
TODO
v5.0 is compatible with Kilo, Liberty and Mitaka Neutron versions.
The biggest change made in v5.0 is the Edge Router model that applies to all v5.0-compatible Neutron versions.
The figure below shows how MidoNet’s Neutron plugin for v1.9 represents the Neutron topology. The external network functionality depends on the presence of the MidoNet Provider Router that is created implicitly as soon as the first external network is created in Neutron. Without the MidoNet Provider Router, Floating IP and Tenant router SNAT do not work.
Neutron tenant routers are connected to the Provider Router in point-to-point overlay link when an external network is specified as 'gateway' on tenant router either in creation or update. The Provider router is invisible to Neutron, so the links between the Provider Router and tenant routers cannot be represented in Neutron. Furthermore, any operation you may want to do on the Provider Router must go through MidoNet API directly (via midonet-cli for example).
Floating IPs are implemented by adding /32 routes to the Provider Router, directing traffic via the appropriate point-to-point link to the correct Tenant router.
The model clearly does not match Neutron’s in following ways:
- External networks hang off the Provider Router, and if there are VMs directly on them, the Provider Router has to ARP reply for all the Tenant SNAT addresses and for all assigned Floating IPs.
- There is no way to easily provide L2 connectivity to all the Tenant routers (something everyone familiar with Neutron’s model initially expects).
In MN v5.0 we decided to harmonize MidoNet’s routing model with Neutron’s without sacrificing our L3 principles and scaling characteristics. In a nutshell, we got rid of the point-to-point links between the Provider Router and the Tenant routers. Having a MidoNet router at the edge of the cloud is still possible but it is now optional. Also, you can not create multiple such routers whereas in v1.9, only one could ever get created. In order to avoid confusion with Neutron 'network provider' extension, these routers are referred to as 'Edge' routers.
The edge routers are nothing more than admin-owned Neutron routers that act as the gateway on the external networks. Because they are Neutron routers, they are visible in Neutron CLI and Horizon. In addition, because the edge routers are optional, the operator is free to choose their own router as the gateway by extending the external network to their physical network. Furthermore, now that the virtual topology resembles closely that of Neutron's, it makes it much easier to migrate from non-MidoNet Neutron deployment.
The figure below shows that external networks no longer hang off of the single edge router, but they sit in between the edge routers and the tenant routers.
In order to configure the edge router, a router port needs to be created and used for other configurations such as BGP. In Neutron, there is no concept of a router port. To represent this foreign concept in Neutron, 'uplink' networks were introduced. These are simply regular admin-owned Neutron networks with type set to 'uplink'. Any port created on this network effectively turns into a router port in MidoNet. Please refer to Quick Start Guide.
Note that it is also possible to bypass the uplink network configuration and use MidoNet CLI as you did in v1.9 on the Provider Router. However, to maintain data consistency with Neutron, it is recommended to use the uplink network API instead.
BGP support is coming to Mitaka in Neutron, but for pre-Mitaka, you still need to use MidoNet CLI.
Starting in Liberty, networking-midonet (the plugin) provides ML2 support. By configuring midonet mechanism driver in the ML2 plugin, it is now possible to run MidoNet and other SDN vendor solutions on a single Neutron deployment. One caveat is that currently there is no support to connect two L2 networks backed by different drivers. For example, you cannot have OVS-backed Neutron network and MidoNet-backed Neutron network to be connected by a Neutron router. However, you can get around it by simply launching a VM plugged into both networks and use it as a router.
MidoNet ML2 mechanism driver is only compatible with v5.0 onward. To configure Neutron to use MidoNet mechanism driver, follow the directions in networking-midonet's README.
Starting with Liberty, MidoNet v5.0 provides FWaaS support. With FWaaS, you can attach a logical Firewall device with ACL rules to any Neutron router.
Refer to the OpenStack FWaaS doc for more information about its API operations.
To configure FWaaS, refer to networking-midonet's README.
Starting with Kilo, MidoNet v5.0 supports port security extension. General information on this feature can be found in OpenStack Wiki (disregard that it says 'ML2'. This feature applies to MidoNet plugin too).
Port security is used to disable anti-spoofing rules that get automatically created when a VM launches with a security group. When port security is enabled, all the security group rules are disabled as well. You can toggle port security on each port or on the network (all ports on the network).
Starting with Liberty, MidoNet v5.0 supports allowed address pairs extension. With this extension, it is possible to allow arbitrary IP/MAC pairs to bypass the anti-spoofing rules. You can also specify /0 address which allows all addresses to skip antispoofing protection.
Refer to OpenStack API documentation for more details.
Starting with Liberty, MidoNet v5.0 supports extra routes extension. With extra routes extension, you can now add arbitrary routes on the router, as long as the destination IP specified is included in the subnets attached to the router.
Refer to OpenStack API documentation for more details.
Starting with Liberty, MidoNet v5.0 supports provider extension, but only to set up the uplink networks explained in the Edge Router Model section. An uplink network is a Neutron 'provider' network with type 'uplink'. Provider extension had to be supported to be able to differentiate networks by type.
Another key feature of MidoNet v5.0 is the distributed metadata service. Until v1.9, to provide metadata service, Neutron's DHCP and metadata agents had to be running. With distributed metadata service, these agents are no longer required as midonet agents themselves act as the proxy for the metadata service (nova API). With this approach metadata requests go directly to the metadata server from the compute hosts as opposed to needing to go through the DHCP agent managed namespaces.
Refer to the MidoNet source for: