“No Open Core” in 2016

Before OpenStack had a name, the “four opens” principles were created to define how we operate as a community.

In 2010 when OpenStack started, it was different from other open source cloud platforms (Eucalyptus) which followed open core strategy of producing a crippled community edition and an “enterprise version”.

Today we have a non-profit independent foundation, which cannot do an “enterprise edition”.

Today member companies build “enterprise products” on top of the apache licensed upstream project. Some are drivers that expose functionality in proprietary components.

What does it mean to “not do open core” in 2016? What is acceptable and what’s not?

Thierry Carrez believes it’s time to refresh this of what is an acceptable official project in OpenStack.

It should have a fully-functional production grade open source implementation

If you need proprietary software of commercial entity to fully use the project, then it should not be accepted in OpenStack as an official project.

These projects can still be non-official projects and still be hosted by OpenStack infrastructure.

Doug Hellmann brings up Poppy [11] which is applying to be an official OpenStack project.

A wrapper to content delivery networks, but there is no open source solution.

The Trouble with Names

A few issues have crept up recently with the service catalog, API headers, API end points, and even similarly named resources in different resources (e.g. backup), that are all circling around a key problem. Distributed teams and naming collision.

Each project has a unique name that is ensured by their git repository in the OpenStack namespace.

There’s a desire to replace project names with generic names like nova/compute in:

service catalog

api headers

Options we have are:

Use the code names we already have: nova, glance, swift, etc.

Upside: collision problem solved.

Downside: You need a secret decoder ring to know what a project does.

Have a registry of common names.

Upside: we can safely use common names everywhere and not fear collision down the road.

Downside: yet another contention point.

Approvals by the various people in the community to have a registry of the common names. Maybe in the governance projects.yaml file [12]?

This list does include only the official projects by the technical committee, therefore only those projects can reserve the common names.

OpenStack Client has already encoded some of these common names to projects [13].

Announcing Ekko – Scalable Block-Based Backup for OpenStack

The goal of Ekko is to provide incremental block-level backup and restore of Nova instances.

Two place with overlapping goals:

Cinder volume without having the incremental backups be dependent.

Nova instances

OpenStack Freezer today leverages Nova’s snapshot feature.

Ekko would leverage live incremental block-level backup of a nova instance.

Jay Pipes begins the discussion on the two projects (Freezer and Ekko) working together to make sure their REST API endpoints are not overlapping. Having two APIs for performing backups that are virtually identical is not good.

The creator of Ekko sees the reason for another backup project because of “actual implementation and end results are wildly different” even if they are the same API call.

Jay doesn’t like that today all the following endpoints exist:

Freezer’s /backups

Cinder’s /{tenant_id}/backups

Having these endpoints make for bad user experience and is just confusing.

The current governance model does not prevent competition of projects. So if two projects overlap in API endpoints, there should be an attempt in collaboration.