OVB 1.0 and Upcoming Changes

The time has come to declare a 1.0 version for OVB. There are a couple of reasons for this:

1. OVB has been stable for quite a while
2. It's time to start dropping support for ancient behaviors/clouds

The first is somewhat self-explanatory. Since its inception, I have attempted to maintain backward compatibility to the earliest deployments of OVB. This hasn't always been 100% successful, but when incompatibilities were introduced they were considered bugs that had to be fixed. At this point the OVB interface has been stable for a significant period of time and it's time to lock that in.

However, on that note it is also time to start dropping support for some of those earliest environments. The limitations of the original architecture make it more and more difficult to implement new features and there are very few to no users still relying on it. Declaring a 1.0 and creating a stable branch for it should allow us to move forward with new features while still providing a fallback for anyone who might still be using OVB on a Kilo-based cloud (for example). I'm not aware of any such users, but that doesn't mean they don't exist.

Specifically, the following changes are expected for OVB 2.0:

• Minimum host cloud version of Newton. This allows us to default to using Neutron port-security, which will simplify the configuration matrix immensely.
• Drop support for parameters in environment files. All OVB configuration environment files should be using parameter_defaults now anyway, and some upcoming features require us to force the switch. This shouldn't be too painful as it mostly requires s/parameters:/parameter_defaults:/ in any existing environments.
• Part of the previous point is a change to how ports and networks are created. This means that if users have created custom port or network layouts they will need to update their templates to reflect the new way of passing in network details. I don't know that anyone has done this, so I expect the impact to be small.

The primary motivation for these changes is the work to support routed networks in OVB. It requires customization of some networks that were hard-coded in the initial version of OVB, which means that making them configurable without breaking compatibility would be difficult/impossible. Since the necessary changes should only break very old style deployments, I feel it is time to make a clean cut and move on from them. As I noted earlier, I don't believe this will actually affect many OVB users, if any.

If these changes do sound like they may break you, please contact me ASAP. It would be a good idea to test your use-case against the routed-networks branch to make sure it still works. If so, great! There's nothing to do. That branch already includes most of the breaking changes. If not, we can investigate how to maintain compatibility, or if that's not possible you may need to continue using the 1.0 branch of OVB which will exist indefinitely for users who still absolutely need the old behaviors and can't move forward for any reason. There is currently no specific timeline for when these changes will merge back to master, but I hope to get it done in the relatively near future. Don't procrastinate. :-)

Some of these changes have been coming for a while - the lack of port-security in the default templates is starting to cause more grief than maintaining backward compatibility saves. The routed networks architecture is a realization of the original goal for OVB, which is to deploy arbitrarily complex environments for testing deployment tools. If you want some geek porn, check out this network diagram for routed networks. It's pretty cool to be able to deploy such a complex environment with a couple of configuration files and a single command. Once it is possible to customize all the networks it should be possible to deploy just about any environment imaginable (challenge accepted... ;-). This is a significant milestone for OVB and I look forward to seeing it in action.