Open Stack

(this is a reprint of a blog post I just made. I'm sending it here 
explicitly too because most (maybe all) of the major users are here. See 
also http://blog.nemebean.com/content/ovb-10-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[1]. 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[1] 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[2] 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.

-Ben

1: 
https://github.com/cybertron/openstack-virtual-baremetal/tree/routed-networks
2: https://plus.google.com/u/0/+BenNemec/posts/5nGJ3Rzt2iL