My Dilemma with Folsom – why I want to jump to G

These views are my own. Based on 1×1 discussions I’ve had in the OpenStack community, I am not alone.

If you’ve read my blog then you know I am a vocal and active supporter of OpenStack who is seeking re-election to the OpenStack Board. I’m personally and professionally committed to the project’s success. And, I’m confident that OpenStack’s collaborative community approach is out innovating other clouds.

A vibrant project requires that we reflect honestly: we have an equal measure of challenges: shadow free fall Dev, API vs implementation, forking risk and others. As someone helping users deploy OpenStack today, I find my self straddling between a solid release (Essex) and a innovative one (Grizzly). Frankly, I’m finding it very difficult to focus on Folsom.

Grizzly excites me and clearly I’m not alone. Based on pace of development, I believe we saw a significant developer migration during feature freeze free fall.

In Grizzly, both Cinder and Quantum will have progressed to a point where they are ready for mainstream consumption. That means that OpenStack will have achieved the cloud API trifecta of compute-store-network.

Cinder will get beyond the “replace Nova Volume” feature set and expands the list of connectors.
Quantum will get to parity with Nova Network, addresses overlapping VM IPs and goes beyond L2 with L3 feature enablement like load balancing aaS.
We are having a real dialog about upgrades while the code is still in progress
And new projects like Celio and Heat are poised to address real use problems in billing and application formation.

Everything I hear about Folsom deployment is positive with stable code and significant improvements; however, we’re too late to really influence operability at the code level because the Folsom release is done. This is not a new dilemma. As operators, we seem to be forever chasing the tail of the release.

The perpetual cycle of implementing deployment after release is futile, exhausting and demoralizing because we finish just in time for the spotlight to shift to the next release.

I don’t want to slow the pace of releases. In Agile/Lean, we believe that if something is hard then we do should it more. Instead, I am looking at Grizzly and seeing an opportunity to break the cycle. I am looking at Folsom and thinking that most people will be OK with Essex for a little longer.

Maybe I’m a dreamer, but if we can close the deployment time gap then we accelerate adoption, innovation and happy hour. If that means jilting Folsom at the release altar to elope with Grizzly then I can live with that.

13 thoughts on “My Dilemma with Folsom – why I want to jump to G”

When is Griz supposed to be released? Timing is everything out there in the jungle for successful implementation of required features and services.

LikeLike

Reply ↓

Rob H on December 19, 2012 at 2:07 pm said:

http://wiki.openstack.org/GrizzlyReleaseSchedule -> April 4. Just a few weeks before the H Summit.

LikeLike

Reply ↓

Jumping to Grizzly sounds like a pragmatic choice to me. Given the way the OpenStack release cycle works it’s not surprising some releases end up with some half complete features.

I’m not criticising the release cycle. Clearly some features take more time than a release cycle allows.

LikeLike

Reply ↓

Rob H on December 19, 2012 at 4:59 pm said:

Thanks. I’m ok with the feature pace, it’s more the deploy lag that I want to stop.

LikeLike

Reply ↓

Is this a symptom of the close release cycles? Where people are deploying this and the fact there isn’t an easy upgrade path from one release to the next, during the “Essex is the one to deploy to production” call to arms, it makes Folsom unnecessary to all but those that are new and would just happen to go with the latest at the time. In a previous role in a very popular UK website, it would take a few months to get this in prod, train staff to use, migrate anything to it and be happy with performance and stability. This would’ve been on Essex. We wouldn’t have considered a move to Folsom and would’ve started to evaluate Grizzly when that became ready in April. We then would’ve looked at upgrading to Grizzily during the H dev cycle – and then probably give that a miss and go for I if deemed necessary.

Does this actually start to look at “Stable” and “Dev” releases ala Linux e.g. Major.Even was stable, Major.Odd was dev ?

LikeLike

Reply ↓

Rob H on December 20, 2012 at 9:59 am said:

Good questions. I don’t think it’s from the release pace – that is driven from the need to schedule summits.

I’d rather see more (incremental) releases. The gate for that is getting the deploy and upgrade work to be in sync with the releases instead of trailing behind. That’s my goal with this post.

LikeLike

Reply ↓