open source marketer and community manager

Month: January 2016

DreamHost has done the right thing, deciding to let go of a portion of its revenues in favor of free SSL/TLS certificates for everybody.

It’s a great pleasure to work for such a company, knowing every day that customers come first and revenues are a side effect. DreamHost may not be the multi-billion dollar juggernaut in the industry but the people here are helpful, nice, competent and believe in what they do.

Let’s Encrypt is another contribution to a free society, pairing up with the contributions Ceph, Astara and OpenStack, WordPress and many other free software/open source projects directly and indirectly sponsored by DreamHost.

The most important gathering of free software and open source enthusiasts in Europe is coming on Jan 30-31, in Brussels and OpenStack will have a table booth there, plus many talks.

I look forward to go there to get the pulse on the open source community regarding the abolition of Safe Harbor provision, and how that impacts users of US-based public clouds, like DreamHost. It’s a complicated issue that I’ve just started looking into. One of the talks I’ll make sure to attend to is Rosario Di Somma’s talk about Magnum in production: he’s been evaluating Magnum for DreamHost and he’ll share the first results of his investigations.

Yesterday’s meeting with the OpenStack App Developer Working Group proved that new developers approaching OpenStack enter a system designed to make them fail.

The community seems to be distracted to uncover new problems while the old and known problems are not being addressed. I’m running for a seat on OpenStack Foundation Board: if you care about the developer’s experience, consider voting for me (search your inbox for OpenStack Foundation – 2016 Individual Director Election, you can also change your vote.)

The first thing you notice in the report? The team at Intel who ran the analysis chose Rackspace as an ‘OpenStack reference cloud’. That choice is debatable but during the meeting when we discussed alternatives, it became clear that there is no good choice! There is no vanilla OpenStack implementation when it comes to application developers, they’re all snowflakes (as Randy Bias put it)… All of the public clouds in OpenStack Marketplace have made choices that affect, one way or another, app developers. If we want to assess the whole development experience on OpenStack, we need a different framework.

As an open source community we can’t compare AWS, Azure and Google Compute to either all of OpenStack public clouds or only one. Powering up TryStack to be an app developers playground wouldn’t really work either.

This is a much larger conversation: we need to discuss more on the User Committee mailing list, do less in-person meetings, share intentions online with others before turning them into actions and waste time.

I’m concerned by the lack of focus within the community: when operating OpenStack became a visible issue, the whole community focused on helping operators out. We need to do the same for app developers.

The OpenStack Technical Committee voted a resolution suggesting to the OpenStack Board to modify the definition of “OpenStack Powered Compute” to include statements such as

An `OpenStack Powered Compute`_ Cloud MUST be able to boot a Linux Guest

This is quite a change in OpenStack DefCore efforts, since as Rob says

The fundamental premise of DefCore is that we can use the development tests for API and behavior validation

DefCore has always been about the OpenStack API and carefully avoided checking the implementation of clouds, leaving enough space for vendors to differentiate their products without harming consumers. An ironic twist of fate is now forcing the whole program to take a stand on implementation, too.

Stating that an OpenStack cloud MUST be able to boot a Linux Guest is the most controversial and I see why the TC is going into this direction: as a OpenStack user, I expect to be able to upload my images in any OpenStack cloud. Given that Linux is the OS of choice for the vast majority of today’s cloud workloads, booting my Linux image is a must have. It’s a practical choice and one that makes a lot of sense.

The problem is that forcing implementation details by the TC is a slippery slope. Will the TC suggest also that any OpenStack cloud must offer a routable IP or boot a VM in less than 5 seconds or that flavor names are always the same across all OpenStack clouds? Granted, all these requests make sense from the perspective of at least some users: there are already lots of unnecessary complications for putting workloads on OpenStack right now.

The question is if those mandates make sense for OpenStack as a whole and I’m not convinced they do. I tend to lean towards two complimentary positions:

make sure that OpenStack Compute Powered clouds are transparent and their behavior is discoverable. Like the OpenStack Foundation exposes the results of the DefCore API compatibility on the Marketplace, I think DefCore should test the implementation of the clouds, public clouds especially and expose the results. This way a user would know that a cloud passes DefCore tests, runs OpenStack upstream code (as done now) and allows uploading/booting Linux guests, offer IPv6 by default, boot in x seconds, has XYZ flavors, allows custom flavors, etc.

DefCore should consider public clouds, hosted private clouds and distributions as different beasts. To me it makes more sense to expect a public cloud to allow uploading Linux guests than mandate the same for a private clod… even less sense for a distribution. The buying process for these is different and the needs for users are different, too.