Floating IP's

This release introduces floating IP's into quantum, first described in #58. It also includes a pretty large refactoring of the etcd code in general to make it more robust and hopefully maintainable moving forward.

Floating IP's operate based on the following setup:

• quantum can be given an arbitrary list of floating ips at run time. Given that those floating ip's are not already assigned as static/dhcp ip's, and exist within the quantum network.
• quantum will attempt to acquire the floating ips ad infinitum.
• quantum will refresh the acquired floating ips once acquired based on the provided floating ip ttl which is defaulted to 10s, each instance will refresh twice per ttl timespan.
• quantum there is no limit to the number of nodes that can participate in a single floating ip "group", meaning any number of instances can attempt to acquire a given floating ip.
• quantum will maintain the same guarantee of continuing to use the last set of observed mappings given a partition occurs and it is not possible to communicate with the etcd cluster. Meaning if connection with etcd is lost quantum will continue to talk to the last node it observed controlling any given floating ip.

Plugin and Networking Backend Rework

This release includes some major refactoring to the plugin system and network backend system. Along with bug fixes, performance improvements, and a myriad of useability tweaks.

Features:

• OpenSSL 1.1.0f based DTLS implementation.
• Compression plugin utilizing the snappy algorithm.
• Encryption plugin which replaces the standard encrypted udp network backend.
• First steps toward a dynamic plugin system.
• Ability to specify the default network config via quantum directly.

Per host encryption

This release brings a brand new feature which allows end users to choose individual servers that can accept un-encrypted communication. The feature is split into two different configuration options, which consist of a boolean flag and a list of trusted servers/subnets to accept traffic from.

The theory is as follows:

• The destination server must have un-encrypted communication enabled.
• The destination server must consider the source server as trusted.

The above allows for the ultimate in granularity over which servers can communicate in an un-encrypted fashion. While also guaranteeing security of the rest of the end-users servers.

Hotfix Release

This is a very simple hotfix release to allow for enabling and disabling autoconfiguration of public ipv4 and ipv6 addressing, in the event a server is known to not have on or the other.

Stability Improvements

This release contains some fixes to reduce some latency spikes that have been observed when go routines where changing OS threads.

Logging, UX, and documentation

This release revolves around enhanced logging and user experience, as well as significant work on documentation.

There are a myriad of smaller changes that include:

• Pretty printing in the stats api when ?pretty is added to the URI
• Better handling of stats aggregation on write failure
• A simpler mechanism governing os and user signals passed to quantum
• Large improvements to startup error logging and handling
• General stability and hardening changes

Bug fix release

A few minor bug fixes are going out with this release, as well as a brand new build system which is far more robust.

Pure etcd client api and bug fixes

This release includes a myriad of small bug fixes and tweaks that make quantum more efficient and stable. The biggest change including a move to using the etcd client libraries directly as opposed to using libkv. This not only reduces complexity but significantly improves flexibility and efficiency of the background processes governing the datastore.

Bug fix release

This includes a minor bug fix to help with some fragmentation issues that quantum was running into over long distances.

Static ip range reservation

This brings functionality to reserve a range of ip addresses within the quantum network, that will get skipped over during dhcp automatic ip addressing. This should help facilitate dual setup approaches, and help to ensure statically addressed servers don't have their ip's stolen by dhcp.