Month: October 2013

OpenStack “Core” and Interoperability

I’ve been following the “what is core?” conversation since the “Incubation Update” committee completed its work some time ago. I’m really happy to see Rob, Alan and others put so much work into moving this along, but each time I try to catch up on progress I find myself a little bewildered.

Since it’s going to be a big topic during next week’s board meeting, I figured I’d try to get my thoughts together here.

What’s it all About?

Even the question bothers me – "what is core?". Why is that an important question?

One reason for its importance is that the bylaws say:

The Core OpenStack Project means the software modules […] for which an OpenStack trademark may be used

In other words, Heat can't call itself "OpenStack Orchestration" unless the Board of Directors approve Heat as part of "The Core OpenStack Project". If that was all this was about, I'd be like "hell yes! Heat should be known as OpenStack Orchestration!". But, it's clearly not just about this, so I tend to ignore this aspect. I don’t actually think much of what is being discussed is all that relevant to this particular issue.

So, what else is this all about? Well, one clue is the emphasis on testing in Rob’s list of “10 core positions”.

OpenStack Core means passing all “must-pass” tests

This is an example of where I get really confused. Maybe I’m just getting hung up on language. I think we’re talking about cloud providers, distributions, vendors, deployers, etc. self-certifying themselves using a test suite in order that they can use the OpenStack trademark. But are we talking about labelling these self-certified clouds as “Core”? Aren’t we making this all very confusing by using the term “Core” both to describe the self-certified clouds/products and also to describe the subset of OpenStack they are required to include? I’d phrase this as:

The OpenStack Core definition includes a list of tests which certified clouds must pass

Anyway, I’m not going to nitpick my way through all of this. I think I understand the intent here, but I like to approach this from an entirely different angle.

A Market of Interoperable OpenStack Providers

(Yes, that is Simon Wardley’s terminology)

We all know that one of the basic goals of OpenStack is for there to be a bunch of public clouds available to users around the world and that interoperability between these public OpenStack clouds will make it easier for users to switch cloud providers and encourage competition between these providers.

To my mind, that’s what this whole “what is core?” conversation is really about. We want to use an OpenStack trademark program to help build this marketplace by enforcing interoperability between clouds which use the OpenStack trademark.

(And yes, I understand that the “what is core?” discussion is also related to questions like what is required of an OpenStack distribution. I’m focusing on the question of public cloud interoperability because I think it’s the most important. IMHO, the whole conversation is pointless unless it moves this particular topic along quickly.)

To do that, we need to define which APIs these clouds must expose, or as Rob puts it – which use cases these clouds must support. To take a simple example, should these clouds be required to expose the Glance API for uploading images?

And here’s where I get confused again. Why are we talking about “what is core?” when we could simply say “which APIs are required to be exposed by certified OpenStack clouds?”. Again, I’m trying not to be a pedant, but the way the question is framed leaves me unsure whether we’re really all talking about the same thing.

I think the focus should be on immediate baby-steps towards kick-starting this marketplace. One simple question – if and when we certify the first batch of interoperable clouds, would we rather have a smaller number of big clouds included or a large number of smaller clouds? In terms of resource capacity provided by this marketplace, I guess it’s more-or-less the same thing.

Let’s assume we absolutely want (at least) a small number of the bigger providers included in the program at launch. Let’s say “small number” equals “Rackspace and HP”. And let’s assume both of these providers are very keen to help get this program started. Isn’t the obvious next baby-step to get representatives of those two providers to figure out exactly what level of interoperability they already have and also what improvements to that they can make in the short term?

If we had that report, we could next do a quick “sniff test” comparing this to many of the other OpenStack clouds out there to make sure we haven’t just picked two clouds with an unusual set of compatible APIs. Then the board could make a call on whether this represents a reasonable starting point for the requirements of OpenStack clouds.

No, this isn’t perfect. But it would be a genuine step forward towards being able to certify some clouds. We would have some data on commonalities and have made a policy decision on what commonalities are required. It would be a starting point.

OpenStack Compatible?

The next big decision for the board is whether a cloud which uses the OpenStack trademark must actually be a deployment of OpenStack’s code. Is this a question of “OpenStack clouds” or “OpenStack compatible clouds”?

I do think it would be damaging to OpenStack if this marketplace took off and was dominated by providers which don’t use or contribute to OpenStack. But, as Rob says, the trademark isn’t the only way of avoiding this situation – there’s also our “velocity and culture”.

I struggle to see how trademark requirements around the use of OpenStack code would work. How do you define which code must be used? Must that code be used unmodified? If not, how much can you change? What does it even mean to “use” a piece of code? That user requests must be executed using that code? Maybe this would just be a “yes, we use and contribute to OpenStack” good faith statement which the Foundation would make a judgment call on? If so, how do we ensure transparency and fairness around how that call is made?

If this question proves to be a stumbling block, I’d prefer to see an “OpenStack compatible cloud” trademark program established quickly. Getting these interoperability guarantees in place for our users takes priority over ensuring that certified providers actually use and contribute to OpenStack.

Conclusion of Sorts

I think our immediate concern should be kicking off a trademark program for certifying interoperability between OpenStack clouds. I’m frustrated whenever I think this “what is core?” discussion is tackling questions which aren’t immediate blockers to making progress on this program.

The board has to make (or oversee the making of) some policy questions.

Firstly, what APIs are required in OpenStack™ clouds? I’d favour starting to answer this by first looking at the current interoperability levels between existing clouds.

Secondly, whether and how we insist on the use of OpenStack code in OpenStack™ clouds. If this turns out to be a difficult problem, then I think we should just start with an “OpenStack™ compatible cloud” program.

A New OpenStack Technical Committee

The results of the OpenStack Technical Committee have just been announced. I’m very grateful to everyone who voted for me. Thanks!

This is going to be a very different committee than previously. For the first time, PTLs of integrated projects do not have an automatic seat. I think this will be a positive change and see TC members generally take more of an interest in cross-project issues. That said, we need to be careful to explicitly include PTLs in decision making which affect their projects.

One thing I’m curious about is how this new TC makeup will affect discussions about the increase in OpenStack’s technical scope. I went through each of candidate’s nomination emails and pulled out some quotes below. To me, this represents a high level of consensus towards a continued cautious and measured growth in the project’s scope … but make your own mind up! I’m actually quite surprised how many candidates felt it was important to give their views on this.

Monty Taylor

I have an expansive view of the scope of OpenStack. I do not think that ‘pure IaaS’ as a limiting factor in the definition serves or will serve any of our users. I think that instead of trying to come up with random or theoretical labels and then keeping ourselves inside of the pre-defined label, we should focus on writing software that solves problems for users.

Russell Bryant

One of the most exciting things for me over the last year has been helping to expand OpenStack by including a number of new projects. I think this growth is important for OpenStack’s success. I would like to continue to help guide this growth and to help figure out how OpenStack can scale as an organization and still be effective.

Anne Gentle

My goal is to provide an inclusive and supportive environment for projects while making OpenStack better for users and admins all the time. We are so fortunate to have the explosive growth and interest in OpenStack, and I want it to continue. We have built upon incredible ideas and I want us to be empowered to innovate.

Mark McLoughlin

We welcomed Heat, Ceilometer, Trove, Savannah, Marconi into the OpenStack family either as integrated or incubating projects. The TC carefully considered each of these applications and my own rule of thumb was “does it have a healthy contributor community and is it a sensible growth of OpenStack’s scope?”. I love to see this sustainable growth in our project and community.

Doug Hellmann

I share the view of many of the other candidates that OpenStack should not limit itself to today’s definition of IaaS. The history of computing is a progression of different levels of abstraction, and what we consider “platform” today may become “infrastructure” tomorrow.

Sean Dague

I’m incredibly excited by OpenStack’s growth (in people, code, scope), which I attribute to an incredibly welcoming and constructive community, and the velocity we get out of our preemptive integration system. As a TC member I’d do my best to ensure those conditions remain. I think we’ve only just begun to see what OpenStack will become [..]

James E. Blair

As a significant OpenStack user, I’m excited about the direction that OpenStack is heading. I’m glad that we’re accepting new programs that expand the scope of our project to make it more useful for everyone. I believe a major function of the Technical Committee is to curate and shepherd new programs through the incubation process. However, I believe that it should be more involved than it has been. We have been very quick to promote out of integration some exciting new projects that may not have been fully integrated. As a member of the TC, I support our continued growth, and I want to make sure that the ties that hold our collection of projects together are strong, and more than just a marketing umbrella.

Michael Still

First off, the TC has incubated a number of projects in the Havana release, and I’d like to see that continue. I think its important that we build a platform that includes the services that a deployer would
need to build a cloud and that those platform elements work well together. Now, its clear that not everyone will deploy all of the projects we are incubating, but I think its still important that they play well together and have a consistent look and feel.

John Griffith

New projects and growth are important to OpenStack however I don’t think that uncontrolled and disjointed growth in the form of new projects is a good thing, in fact I think it’s detrimental to OpenStack as a whole. I personally would like to see the TC have more involvement in terms of recommending/investigating new projects before they’re proposed or started by others. By the same token, I’d also like to see the TC take a more active role in the projects we currently have and how they all tie
together. I personally believe that having 10 or so individual projects operating in their own silos is not the right direction. My opinion here does NOT equate to “more control”, but instead should equate to being more helpful. With the continued growth of OpenStack I believe it’s critical to have some sort of vision and some resources that have a deep understanding of the entire eco-system.

Mark McClain

The issue of scope was a recurring theme during my recent term on the TC. As the OpenStack ecosystem grows beyond Infrastructure as a Service, the committee needs to more clearly define the criteria used to determine the kind of projects and programs that fit within the scope of integrated releases and how they move through the progression of incubation to graduation. In addition to defining the criteria, the Technical Committee should to work develop policies and procedures to provide some guidance to projects which are outside of the scope an integrated release, but valuable to our community.

Robert Collins

(I don’t see a directly relevant quote from Robert)

Oct 3rd OpenStack Foundation Board Meeting

On Oct 3rd, the OpenStack Foundation Board held a two hour conference call meeting which was open to anyone to join. The agenda was published in advance.

As usual, this my informal recollection of the meeting. It’s not an official record, etc. Jonathan published an official summary on the foundation mailing list.

Preliminaries

Our chairman, Alan Clark began the meeting by holding a roll call. If my count was correct, we had 21 of the 24 members of the board on the call, which is a pretty good turnout.

Alan introduced Chris Kemp as a replacement for Devin Carlen who had been representing Nebula and the Gold Members. Chris briefly explained that changes in his role at Nebula has left him more time for “strategic stuff” and is delighted to spend more time with the OpenStack community and join the board. He thanked everyone for their work in progressing the foundation to date.

Before getting down to business, we quickly voted to approve the minutes of the previous meeting.

Executive Director Report

Jonathan Bryce took the floor and gave a really excellent update on the Foundation’s progress.

First off, he described the launch of the OpenStack Foundation Training Marketplace at LinuxCon in New Orleans. The site now has 12 companies listing training events at over 30 cities around the world and has seen over 10,000 unique visitors over the past 2 weeks. He reiterated how one of the Foundation’s stated priorities for this year is to help training providers get the word out on their education programs and thereby expand the pool of people with OpenStack skills.

Next up, Jonathan gave an update on preparations for the OpenStack Summit in Hong Kong. Everything is coming together nicely and the finalized speaking agenda has now been posted. He explained that, while they had received some 250 submissions for the summit in Portland, there were over 600 submissions for Hong Kong and yet not many extra speaking slots. The track chairs had a tough job whittling down the submissions but he thinks the end result is an agenda packed with great sessions. Jonathan warned that, unlike previous summits, we have a hard limit on the number of attendees and the “full access” passes will sell out in the next week or so.

Eileen asked exactly how many full access passes were issued and Jonathan explained there are 2,000 but that there are many more passes for the general sessions and expo hall. Joseph asked for some insight into the demographics of the registered attendees and how it compares to previous summits. Jonathan felt that we would see a large number of attendees from the region and that, while some companies may have reduced their numbers travelling from further afield, there would still be plenty of representation from all of the companies we are used to seeing at summits.

The discussion then moved on to looking ahead to 2014 and a sneak peak of next year’s budget. Jonathan explained how 2013 was a great year financially – particularly because the summits were larger than expected – and the Foundation goes into 2014 with a healthy budget surplus of over $1M. We expect to continue to see large summits and this will lead to increased revenues and expenses. Jonathan expects the Foundation to continue to invest in technology and infrastructure over 2014. He described the Foundation funded projects in 2013 to improve the member database and tie it to the contributor agree process and an improved system for handling summit speaker submissions.

Rob Hirschfeld asked whether the Foundation had budgeted for certification testing infrastructure being proposed as part of the “what is core” discussion. Josh felt this it not be necessary for the Foundation to fund this, and there was a brief data tracking and authentication systems.

Jonathan continued by describing the rapid growth in Foundation staff during 2013, but that he expects ongoing staffing costs to have mostly levelled off for 2014. He went on to talk about how he sees the role of the Foundation over the next year to be around connecting different parts of the community, helping to gather data on users and deployments and sharing information with the world about new features in each release.

One Jonathan had finished, Lew Tucker congratulated Jonathan on the progress and asked whether a written summary could be prepared for board members so that we could help get the word out. Josh pointed out that we were soon due an annual report which would contain much of this information.

Josh then asked a question about the project budget for gold member fees and how many new members this assumed would be added in 2014. There was some confusion on the issue because gold member fees are based on the member’s revenue, but the conclusion was that the addition of 4 new members was projected. This would bring the total number of gold members up to 20 out of a total possible 24 members.

Election Committee Report

Next up, Todd Moore delivered an excellent summary of the discussions and conclusions of the committee established to consider whether any changes were need for the individual and gold member director election systems and what those changes might be.

Todd’s report – which will be published in full soon – described how we considered three separate questions. Firstly, whether and how concerns about the fairness of the individual member director election system (particularly the issue of large blocks of affiliated voters) should be addressed, secondly whether we should consider any rule changes around foundation employees eligibility for the individual member director election and, finally, whether the eligibility rules for the 2013 gold member director elections had been properly enforced.

The last topic was easily dispensed with – Todd and the committee worked with the foundation staff to verify that all eligibility rules (i.e. eligibility as a candidate and eligibility to vote) had been properly enforced.

The first topic proved to be substantially more contentious. The pros and cons of changing to an STV based election system or tweaking the rules of the current system to halve (from 8 to 4) the number of votes which you could allocate to a single candidate were explained in great detail. Todd explained how the committee felt that changes were not necessarily warranted but that it would be wise to seriously consider the option of the “max 4 votes per candidate” tweak.

A motion was proposed to not fundamentally change the voting system and was almost voted for until it became apparent that Monty wanted to speak but was unable to come off mute. Once that was sorted out, Monty stated that the cumulative system was utterly broken and that block voting did, in fact, influence the outcome of the election. He felt strongly that a change to STV was needed. The debate then took off in earnest with many well put points made by various members. I explained how I agreed fully with Monty but that I was convinced by the “it’s working reasonably well; this doesn’t warrant a the disruption of a bylaws change” but that we needed to be alert to any renewed concern from members after the next election. In the end the vote was passed with no abstentions and Monty voting against.

The discussion then moved on to the question of the “only 4 votes per candidate” tweak. Much of the discussion hinged on whether this tweak required a bylaws change. The election committee and Jonathan felt that it was compatible with the “cumulative voting system” language in in section 3.9a of the bylaws but legal counsel for the foundation (Mark Radcliffe) disagreed strongly and felt “cumulative voting” was “binary in the eyes of the law”. Since the committee had suggested this tweak on the understanding that it was easy to implement, the idea was dropped.

Next, we discussed the second issue – the question of foundation employees on the board. The committee did not have a consensus recommendation on this but Todd did summarize the different viewpoints and arguments. One approach proposed that the executive director would be granted a new, automatic seat on the board and (because there is a limit of two members per organization), only one additional foundation employee could be elected to the board rather than the current limit of two employees. There was lots of debate and I felt Jonathan’s input was particularly interesting – that he did not see the need for an automatic executive director seat and he had reservations about restricting employees from being directors since they could bring invaluable and passionate input, should the electorate choose to elect them. In the end, it was felt there was not sufficient cause to warrant a disruptive bylaws change and the motion was withdrawn.

So, in summary, there will be no election system changes proposed to the electorate during this cycle. However, the board again re-stated the importance that all members adhere to the community code of conduct which states:

Respect the election process. Members should not attempt to manipulate election results. Open debate is welcome, but vote trading, ballot stuffing and other forms of abuse are not acceptable.

Finally, the committee took an action item from the board to analyze the results of the next election and provide the board with a report on the potential effect of any of the options proposed.

Wrapping Up

Because of the lengthy debate on the election system, we had run out of time and the rest of the agenda had to be postponed until the in person board meeting in Hong Kong.

Edits

  • Changed from “legal counsel for the board” to “legal counsel for the foundation”. Thanks to Richard Fontana for the correction.
  • Included a reference to the code of comment. Thanks to Rob Esker for his question.