Open Mic Spotlight: Flavio Percoco

Screen Shot 2013-09-12 at 8.40.46 AMThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun. 

Flavio spends most of his time hacking on storage (Glance [core member], Cinder, Swift) and messaging (Marconi [core member]) modules. He has both Italian and Venezuelan roots, and is currently based in Italy where he works remotely for Red Hat. Flavio is also an actively open-source contributor and part of Mongodb Masters group.

Prior to Red Hat, Flavio worked on Big Data oriented applications, search engines and message systems. He was also an active member of Gnome’s a11y team where he contributed to Orca and created MouseTrap, a head-tracker application. Outside Red Hat, he likes to take pictures, swim, travel, hang around with family and friends and whatever seems interesting. You can follow him on Twitter at @flaper87.

1. What is your go-to beverage or snack while coding? 

Coffee and Gummy Bears. Here’s proof:

https://dl.dropboxusercontent.com/u/671680/IMG_20130903_143124.jpg

2. What behavior has helped you get the furthest as a developer? 

“Be humble about the things you know and fearless about the things you don’t know… And keep going.” I always remind myself this.

Computer Science is one of those careers where people never stop learning. It keeps evolving every second, there are always new things to learn, share or do.

I consider myself a very passioned developer and I’m always looking for new things to learn and share. Whenever I get the chance, I dig deeper on the things I like the most and I’m always looking forward to share everything I know with other people.

This way of thinking has taught me that knowledge is worthless if you don’t know how share it.

3. Why did you get into computer engineering?

I’m not one of those who started playing with computers since he was 3 years old. I spent my childhood playing outside my house rather than inside it. I started playing with computers – and I mean programming – when I was almost out of high school – or was I out already? mmh – and I completely fell in love with it. My first distro was RHEL and after it I jumped through a whole bunch of different distros.

My other options besides computer engineering were: Physics, Medicine or Psychology but I’m programmatically lazy so, here I am. I still want to study Physics, though.

4. What are your tips or tricks for surviving jet lag or long conferences?

Trust your clock, it’s always right (unless you forget to change it to the local time).

Don’t think about how tired or hungry you are because you’re not. If your clock says 12:00 then it is time for lunch, if it says 20:00 it’s time to have dinner and if it says 2:00 then you can be tired and go to bed.

I call that: “Biology by approximation”

5. Not counting the obvious (your colleagues or close former colleagues), who have you worked with closely, built a relationship with or learned the most from in the community? Why? 

Without any specific order:

Doug Hellman: No matter how or with regard to what, I always learn something new from him. Email threads, reviews or code, it doesn’t matter, he’s always teaching me something.

Devananda van der Veen: When we met at the last Europython, we not just talked about technology but also about Philosophy and Buddhism. I really enjoyed our conversations and learned at lot from them.

The whole Marconi team: Those guys rock. We’ve been working very closely since the project started. We’ve made calls, meetings and hung around on IRC. All this time, we’ve shared and learned from each other. Also, I’d dare to say that Marconi’s irc channel is the funniest throughout OpenStack.

 

Tags:

OpenStack Community Weekly Newsletter (Aug 30 – Sep 6)

Register Now For The Summit in Hong Kong
在全体大会中将提供英文至中文之即时翻译。 要得到更多信息, 请查阅注册信息页

OpenStack Heat and Ceilometer got their dashboard panel

The Havana milestone release of the Horizon dashboard brought an absolutely wonderful panel for Heat, the orchestration service and Ceilometer, the metering service. Enjoy a preview before the Havana’s official release.

OpenStack Icehouse Incubation Roundup

The OpenStack Technical Committee met this week to consider the status of incubated projects for the upcoming Icehouse cycle. As a result, database provisioning (codename Trove) will be an official part of the Icehouse (2014.1) release, while message queues (codename Marconi) and bare-metal server provisioning (codename Ironic) will be in incubation with a view to becoming official in the as-yet-unnamed J (2014.2) release.

Bringing Go To The Cloud With The Gophercloud SDK

Go is a rapidly emerging programming language created out of Google by Rob Pike and Ken Thompson. Rackspace is investing in Go by creating a multi-cloud software development kit (SDK) for the Go programming community called Gophercloud. It will support OpenStack first, Rackspace Cloud second.

Scaling the OpenStack Test Environment

A year ago James Blair introduced Zuul, a program he developed to drive the OpenStack project’s gating system. In short, each change to an OpenStack project must pass unit and integration tests before it is merged. Over the past year, the OpenStack project has grown tremendously, with 62 git repositories related to OpenStack, 30 for the project infrastructure, and an additional 75 unofficial projects that share the same testing infrastructure. In all, the development infrastructure currently serves 167 repositories. They run up to 720 test jobs per hour, and our dynamic provisioning system has pushed our test node count up to 328 nodes online and running tests simultaneously. Over the past year, the OpenStack Infra team made a large number of changes to prepare for this load. This blog post by jeblair has some of the key innovations that help us test at scale.

For VIM users out there: qtpy.vim

A simple way of running python unit tests from within VIM based on the cursor location. Useful for receiving immediate feedback as you write tests, despite what test runner or framework your project uses to run its tests.

Tips ‘n Tricks

Upcoming Events

Reports from Previous Events

Other News

Welcome New Developers

Is your affiliation correct? Check your profile in the OpenStack Foundation Members Database!

  • Subashini Soundararajan, Rightscale
  • Sam Alba, dotCloud Inc
  • Itzik Brown, None
  • William Van Hevelingen, Portland State University
  • Brianna Poulos, JHU/APL
  • Łukasz Jernaś, Allegro Group
  • Yangyang Zheng, CIeNET Technologies
  • Valerii Zhelezniakov, None (Mirantis?)
  • Rob Raymond, HP
  • Daniel Izquierdo, Bitergia
  • Swapnil Kulkarni, None
  • Robert Tingirica, Cloudbase Solutions
  • Shaun McCance, Cisco
  • nancykyo, ?
  • Abishek Subramanian, Cisco
  • Zhengguang Ou, None
  • Simon, Unitedstack

OpenStack Reactions

Trying to understand how the Swift ring work

The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment.

 

First meeting of OpenStack Venezuela

The Venezuelan OpenStack community had its first full day meeting on August 24 in Caracas and it was a big success.  Nelson Perez, gave a general introduction to  virtualization talking about what it is, why it’s useful and finally an overview of  hypervisors.  Enrique Femin then talked about cloud computing giving general definitions, principles and types.  Finally, Ender Mujica presented one introduction to OpenStack: What is it? How to use it, its history, the community, developers and members, and of course an overview of OpenStack’s architecture, components and services.

Lunch was followed by 3 live demonstrations. Ender Mujica presented a installation from scratch on Ubuntu 12.04 using all the component with Neutron and Cinder. He also showed some functions of the dashboard, like how to launch virtual machines with network, how to create a volume and attach it to a VM.

Reinaldo Martinez presented an installation on Centos 6 and Debian 7 and some details about the other functions like namespaces, dhcp, how to create networks, load balancing with 3 web servers on VM, glance with swift and with LVM, horizon and the command line tools and more.

The intensely technical day was followed by appetizers, soft drinks, water, beers, some awesome mugs and OpenStack stickers.

The scripts to install on Debian and CentOS were released to the community.

Tags:

Open Mic Spotlight: Julien Danjou

JulienDanjouThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun. 

Julien is a Free Software hacker working as a independent consultant. He’s the Project Technical Leader for OpenStack Ceilometer, and a member of Oslo core. He also contributes to other free software projects, like Debian and GNU Emacs, regularly. You can follow him on Twitter @juldanjou. 

1. What is your go-to beverage or snack while coding?

Coffee, without surprise, especially in the morning. However, I can’t drink coffee during my late evening coding sessions, for obvious reasons (I do need to sleep), so I enjoy scotch whisky once in a while.

 2. What behavior has helped get you the furthest as a developer?

I think being pragmatic most of the time helps a lot. It’s very hard to keep this in sight, as I, like many developers I guess, do have a tendency towards building some sort or perfect systems. But you have to make compromises all the time, and being ready to do so every day helps a lot building successful communities and projects. Also when dealing with open source projects, being humble and diplomatic is also a key to get your contributions accepted. You have to remember that you’re entering a zone where people don’t owe you anything and may be smarter than you.

3. What is your favorite project that you’ve contributed code to?

I think that it’s the on I use the most (I’m typing this in it), and it’s GNU Emacs. I do a lot of things with Emacs, coding obviously, reading and writing my mails, chatting on IRC, etc. It’s a really powerful tool for developers, and is easy to leverage to help in you in any tasks. And it got me into Lisp, a fabulous programming language, I’m thankful for that!

4. Have you organized an OpenStack meet-up/event or spoken about OpenStack at an event? What did you learn? What was the best part?

I spoke at a couple of events, and it was really great. I think the best part is getting feedback from users on what you built. This is really rewarding at a personal level, and valuable at a product level. That way, you know that you’re on the right track, or not.

5. Where’s your favorite place to code? In the office, at a local coffee shop? In bed?

This isn’t going to be original, but I do like to code at my desk at home. I find it hard to work in corporate offices most of the time, due to the noise, people going in and out, etc. I do prefer quiet and calm places so I can concentrate. Though I experienced doing OpenStack code reviews from a deckchair in the garden this summer, and it’s definitely something that I’ll have to try again!

Tags:

OpenStack Community Weekly Newsletter (Aug 23-30)

Register Now For The Summit in Hong Kong
<在全体大会中将提供英文至中文之即时翻译。 要得到更多信息, 请查阅注册信息页

Ambassador Program – Specifics

Following from the previous post, we’ve had a range of people express their support for the program and quite a number already looking for the application form! So, some more details about the Ambassador Program. Ambassadors will be recognised on the OpenStack website for their efforts, and provided with support from foundation staff to conduct their duties. They will also get access to a funding program – allowing them to request funds for activities of impact in their region. We’d also expect ambassadors to attend the summits, and the Foundation would likely assist if it wasn’t possible for them to be there using their own methods.

How Heat Orchestrates your OpenStack Resources

One of the great things about orchestration is that it automatically figures out the operations it needs to perform. So whenever you deploy (or modify) your infrastructure you need not write a script to do so; you simply describe the infrastructure you want and the orchestration engine does the rest. Zane Bitter describes how this works in Heat.

Autoscaling with Heat and Ceilometer

Like AWS CloudFormation, Heat allows to create auto scaling stacks. In order to do this, some metrics need to be retrieved from your VM and some actions need to be triggered when a specified event occurs on these metrics. These actions are usually upscaling (create some new VMs) or downscaling (destroy some Vms). Starting with the Havana version (currently trunk), Ceilometer can now trigger actions when something happens to these metrics by creating alarms. The Heat agent inside the VM is no more needed.

Taking OpenStack Core discussions to community

We’ve been building up to a broad discussion about the OpenStack Core and I’d like to invite everyone in the OpenStack community to participate (review latest). Alan Clark (Board Chairman) officially kicked off this open discussion with his post on the OpenStack blog last week.  And we’re trying to have face-to-face events for dialog like the Core meetup tonight in San Francisco.  Look for more to come! Of course, this will also be a topic at the summit. The Board needs to move this forward in the November meeting, so NOW is the time to review and give us input.

The OpenStack T-Shirt Design Contest Winner is…

Raul Chan’s design:

Winning T-shirt Design

OpenStack in Production

OpenStack Swift & many small files

Spil Games has been running Swift for more than two years now, hosting over 400 million files with an average file size of about 50 KB per object. They have a replica count of three so there are1.2 billion files to be stored on the object servers. Generally speaking, Swift has turned out to be a solid object storage system. They however run into some performance issues and in a blog post they describe how they analyzed and solved them.

Tips ‘n Tricks

Upcoming Events

Reports from Previous Events

Other News

Security Advisories

Got answers?

Ask OpenStack is the go-to destination for OpenStack users. Interesting questions waiting for answers:

Welcome New Developers

Is your affiliation correct? Check your profile in the OpenStack Foundation Members Database!

  • Jakub Krajcovic, Rackspace
  • Michal Jura, Suse
  • Maris Fogels, None
  • Tim Smith, Gridcentric
  • Claudiu Belu, Cloudbase Solutions
  • David Stanek, AG Interactive
  • John Dennis, Red Hat
  • Mikhail Dubov, Mirantis
  • Scott Radvan, Red Hat
  • Michael Solberg, Red Hat
  • Auston McReynolds, eBay
  • Ilya Sviridov, Mirantis
  • Chris Johnson, Rackspace

OpenStack Reactions

When a Hyper-V driver developer finds a dependency on linux in oslo

The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment.

Tags:

Open Mic Spotlight: Julie Pichon

jpichonThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun. 

Julie Pichon is a Software Engineer at Red Hat. She focuses her efforts on Horizon, the OpenStack web dashboard, and is a member of the core team. You can follow her on Twitter @jpichon_net. 

1. What do you do when you’re not obsessing over and working with OpenStack?

I’m usually found immersed in learning Japanese, or organising events and workshops for my local hackerspace here in Dublin (Tog.ie).

2. What was your first commit or contribution and why did you make it?

My first contribution was a patch for the Horizon security groups form, to allow a security group to set itself as an allowed source of inbound traffic. I’d been working with AWS for a while and the problem was fresh in my mind, and the fix looked simple enough for a first contribution. It was interesting to figure out places where Horizon uses Django differently, such as the test fixtures. Getting set up with the development tools like Gerrit was a breeze thanks to the wiki documentation.

3. What other OpenStack developers deserve a shout out for the work they’re doing in the community? Who are our unsung heroes? Your own?

I’m really excited about the work Daisy (Ying Chun Guo) is doing to shape the internationalization team and increase the visibility of the translation and internationalization work. It’s important in order to make OpenStack more accessible and increase its adoption, and related issues shouldn’t come as a second thought.

4. What do you think are the benefits of the open, community-driven approach to development?

Personally, I enjoy the way it brings together people from all over, with their own perspective and strengths to enrich the project with. It avoids wasted, duplicated effort behind walls. It’s a great way to get interested people involved and to bring them up to speed, making the project more sustainable. There are many more.

5. What is your favorite productivity hack? Secret trick? Shortcut you’re slightly embarrassed to admit?

Since I usually work with different versions of devstack and openstack in multiple VMs, I found my life greatly improved when I discovered emacs’ TrampMode for editing remote files. I find it much easier to have all the files I need open in the same editor on my main machine rather than sessions or editors open everywhere. It’s saved me a couple of time too, when a VM died an untimely death…

 

Tags:

Ambassador Program – Specifics

Following from the previous post, we’ve had a range of people express their support for the program and quite a number already looking for the application form! So, some more details about the Ambassador Program…

Ambassadors will be recognised on the OpenStack website for their efforts, and provided with support from foundation staff to conduct their duties. They will also get access to a funding program – allowing them to request funds for activities of impact in their region. We’d also expect ambassadors to attend the summits, and the Foundation would likely assist if it wasn’t possible for them to be there using their own methods.

Should I Apply?

Great leaders know when to be modest, but if you feel like you’re already doing the kind of things listed in the previous post, we’d like to recognise your efforts – so do consider applying. Initially we’re being a little more cautious and smaller scale, iterating our way toward a larger more active program – but putting your application in at the beginning will ensure you’re considered later too in the event you’re not selected initially.

How can I Apply?

This is an exciting new program, and we want to get right from the outset.
To that end, we want to get some more feedback before starting it. So, to begin with, start thinking about whether you or someone you know is ambassador material – and then let us know whether you think there’s something that should be changed! So, please continue to discuss on the mailing list/comment section, or, if you would feel more comfortable raising your issues in private – email [email protected]
Following this period of consultation, we’ll open for selections, aiming to have the first OpenStack Ambassadors bestowed their title in September.
While the discussion continues, if you feel ready, you can put in an application at the form here.

Frequently asked questions

When is all this going to happen?

We hope to have our first tranche of ambassadors entitled by September, so we can get the program running before the summit. We want to get this done as soon as manageable, since we expect it to go a long way to solving some problems that exist right now.

How much do ambassadors get paid?

They are paid in love – this is a volunteer position.

How big will the regions be?

Initially: big. We’re starting with a small number of ambassadors so we can learn before scaling up. We also want to avoid situations where there are many ambassadors in one region – hence the selection criteria related to geography.

How does “Ambassador” relate to “User Group Leader”?

OpenStack Ambassador and OpenStack User Group leader are two distinct roles, which can of course be fulfilled by one person, but they have distinct responsibilities. The Ambassador may be involved in running their local meetup group, but they’ll be chatting to the User Group Leaders in their region about how to best help – not taking over!

What will the term length be for ambassadors?

It’s a ‘job for life’. We believe that the kinds of people who would be eligible to be ambassadors will know when to step down gracefully.

How will we manage misuse of the ambassador title?

This question comes up frequently, but we have faith in our community. We’ll be applying selection criteria to weed out any undesirables at the beginning, but then keeping in constant contact with the ambassadors to look for early signs things aren’t going the right way. Community members are also welcome to help us looking out for misuse of the title.

OpenStack Community Weekly Newsletter (Aug 10-23)

Cast your vote for the presentation to be presented at OpenStack Summit, November 5-8, in Hong Kong
在全体大会中将提供英文至中文之即时翻译。 要得到更多信息, 请查阅注册信息页

Introducing the OpenStack Ambassador Program

OpenStack Community Manager Tom Fifield started the discussion on the formation of an OpenStack Ambassador Program, which aims to create a framework of community leaders to sustainably expand the reach of OpenStack around the world. We would like to recognize and further empower these community members to achieve the OpenStack mission, as well as provide more structure and resources to the growing community and user groups. Your feedback would be excellent! For more specifics on the program, and information about becoming an ambassador, stay tuned for the next post.

Managing identities in the cloud

CERN has 11,000 physicists who use the lab’s facilities including the central IT department resources. As with any research environment, there are many students, PhDs and other project members who join one of the experiments at CERN. They need to have computing accounts to access CERN’s cloud but we also need to make sure these resources are handled correctly when they are no longer affiliated with the organisation.

Why OpenStack Puppet modules did not have vacation

A lot of work has been done on Puppet modules lately. There is no doubt to say that puppet modules are designed for high-quality and best-practices configurations around an important community who takes care of those concepts.

Yet another way to monitor OpenStack

Emilien Macchi decided to write some useful scripts to check if every OpenStack service are running. He was not fully satisfied with current methods because he feels they lack some deepness.

refined: 10 OpenStack Core Positions

OpenStack Foundation Board member Rob Hirschfeld keeps iterating looking for a proposal to define “what is core” in the context of OpenStack. This is a must-read for anybody interested in joining the meeting in San Francisco on Aug 27.

Tips ‘n Tricks

Upcoming Events

Reports from Previous Events

Other News

Got answers?

Ask OpenStack is the go-to destination for OpenStack users. Interesting questions waiting for answers:

Welcome New Developers

Is your affiliation correct? Check your profile in the OpenStack Foundation Members Database!

  • Jaime Gil de Sagredo Luna, StackOps
  • Joshua Hesketh, Rackspace
  • Oleg Gelbukh, Mirantis
  • Jiri Stransky, Red Hat
  • Steffen Gebert, None
  • Trevor Robert, Jr, Cisco
  • Pei Zhen, None
  • Sabari Kumar Murugesan, Vmware
  • Ignacio Barrio, Stackops
  • Charles V Bock, Intel
  • Jordan OMara, Red Hat
  • Sarah Novotny, Meteor Entertainment
  • Maksym Iarmak, Mirantis
  • Marton Kiss, Fremont Ltd
  • Petr Blaho, Red Hat
  • Ryan Hsu, Vmware
  • Alan Jiang, IBM
  • Zhang Guoqing, None
  • Hwbi
  • Abhijeet Malawade, NTT Data
  • Shuangtai Tian, Intel
  • Jake Liu, None
  • Vladislav Kuzmin, Mirantis
  • Nejc Saje, Xlab d.o.o.
  • Peter Mooshammer, None
  • Floren Llanos, None

OpenStack Reactions

How I feel when a -1 turns into a +1 after explanation

The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment.

 

Tags:

The OpenStack T-Shirt Design Contest Winner is…

In June the OpenStack Foundation launched its first T-Shirt Design Contest encouraging the community to help contribute to our collection of unique and fun shirt designs. Two months later it’s now time to announce the proud winner – Raul Chan!

Here is Raul’s design:

Winning T-shirt Design

Winning T-shirt Design

Raul is a 17-year-old student in Hong Kong, who is incredibly passionate about design. He’s been drawing, sketching and designing for a year now with the dream to become a graphic designer one day. You can check out his other designs on his Instagram account ,@d_raul.

Raul Chan

Raul Chan

When we asked what his inspiration was for the OpenStack design, he said “as I know that OpenStack is a cloud operating system which processed lots of data for many companies, I used the logo of OpenStack to form a ‘cloud’. Besides, different colors of the ‘cloud’ represent the diversification of OpenStack.” Raul isn’t very involved with OpenStack but became interested in it as it became increasingly popular in China.

Raul’s design will be featured on T-Shirts that will be given out at LinuxCon Cloud Open in New Orleans in September and at other events where OpenStack will have a presence later this year and in early 2014.

For his efforts, we’re sending him and his family several T-Shirts and a free ticket to the OpenStack Summit in Hong Kong. So say hello if you see him around!

PS: If you want to pen the next design that’ll decorate the OpenStack T-Shirts – look out for the 2014 T-Shirt Design Contest. We’ll be announcing it on the OpenStack blog and our other social media channels in the coming months.

Tags:

Addressing the topic of ‘Core’ through Spider

The word “core” carries with it a wide range of meaning and implication for those involved within the OpenStack community. What we’ve discovered through ongoing discussions is that the goals of one audience simply aren’t necessarily the goals of the other audiences – in fact, in some cases, they’re opposed!

We first began the journey to refine the definition of core through a work effort called IncUp.  IncUp was a combined effort of TC and board members that resulted with improvements to the Incubation process. That effort also helped draw out the complex nature of defining core.  The complexity is due to the varied impact core has upon OpenStack users and contributors, as well as the ecosystem as a whole.

Addressing The Problem
On assignment from the Board, Rob Hirschfeld and I began meeting to further the progress of defining core. The first step in this process was to examine and define the goals of each audience, which Rob detailed in a series of blogs[1] outlining the thought processes we went through.

Shortly after we began this process, we quickly realized that the goals amongst these various audiences would either be aligned or in tension. Using different colors to map the goals and tensions on a whiteboard, we created a massive multi-colored “spider” graph, which became more of a mind map. Thus, we refer to the current effort as the “spider discussions” or simply spider.

Problem Statement/Goal
At the highest level, this spider effort is about advancing the OpenStack mission of producing the ubiquitous Open Source cloud computing platform. The key efforts within this process include defining the set of components, processes and criteria needed to protect the brand, provide users a good experience, and reinforce a collaborative community.OpenStack marks are the tools that the Foundation has to define and defend those keys.
In order for OpenStack implementers to use the OpenStack mark, the Board was chartered to provide specific and verifiable criteria. However, these do not currently exist in a usable form.  Thus, our “what is core” discussions and efforts seek to determine those criteria.
Statements of Position
Spider focuses on breaking down those criteria of core into referenceable position statements.  Those statements will form a basis to draw upon so that we may keep the decision making – and eventual implementation – on a progressive track.There are currently 10 evolving position statements:1.     Implementations that are core can utilize the OpenStack trademark (OpenStack™)
1.     This is the legal definition of core, as well as why it matters to  the community.

  1.  We want to make sure that the OpenStack™ mark means something.
  2. The OpenStack™ mark is not the same as the OpenStack brand; rather, the Board uses its control of the mark as a proxy to help manage the brand.

2.     Core is a subset of the whole project

  1. The OpenStack project is intended to be a broad and diverse community with new projects entering incubation, with new implementations frequently added. This innovation is vital to OpenStack but separate from the definition of core.
  2. There may be other marks that are managed separately by the foundation and available for the platform ecosystem at the Board’s discretion.
  3. The “OpenStack API Compatible” mark is not part of this discussion and should be not be assumed.
3.     Core definition can be applied equally to all usage models

  1.  There should not be multiple definitions of OpenStack, regardless of the operator (public, private, community, etc.).
  2. While expected that each deployment is identical, the differences must be quantifiable.

4.     Claiming OpenStack requires use of designated code frameworks

  1. Implementations claiming the OpenStack™ mark must use the approved API framework code.\
  2. Entities which only pass all the tests but do not use the API framework will not be considered or be approved as part of OpenStack.This prevents entities from using the API without joining the community, as well as surfaces bit-rot in alternate implementations to the larger community.
  3. By implementing this requirement,  interoperability is greatly improved, as there is more shared code between implementation

5.     Projects must have an open reference implementation

  1. OpenStack will require an open source reference base plug-in implementation for all projects (if not part of OpenStack, license model for reference plug-in must be compatible).
  2. We define a plug-in as alternate backend implementations with a common API framework that use common _code_ to implement the API.
  3. This establishes the expectation that projects (where technically feasible) will implement plug-in or extension architecture.
  4. This is already in place for several projects and addresses ecosystem support, further enabling innovation.
  5. Reference plug-ins are, by definition, the complete capability set. It is not acceptable to have core features that are not functional in the reference plug-in.
  6. This will enable alternate implementations to offer innovative or differentiated features without forcing changes to the reference plug-in implementation.
  7. This will also enable the reference to expand without forcing other alternate implementations to match all features and recertify.

6.     Vendors may substitute alternate implementations

  1. If a vendor plug-in passes all relevant tests then it can be considered a full substitute for the reference plug-in.
  2. If a vendor plug-in does not pass all relevant tests then the vendor is required to include the open source reference in the implementation.
  3. Alternate implementations may pass any tests that make sense and should add tests to validate new functionality.
  4. They are also required to have all the must-pass tests (see #10) to claim the OpenStack mark.

7.     OpenStack implementations are verified by open community tests

  1. OpenStack implementations by vendors must achieve 100% of must-have coverage.
  2. Implemented tests can be flagged as must-have required list.
  3. Certifiers will be required to disclose their testing gaps.
  4. This will put a lot of pressure on the Tempest project.
  5. Maintenance of the testing suite will become a core Foundation responsibility, which may require additional resources.
  6. Implementations and products are allowed to have variation based on publication of compatibility.
  7. Consumers must have a way to determine how the system is different from reference (posted, discovered, etc.).
  8. Testing must respond in an appropriate way in BOTH pass and fail (the wrong return rejects the entire suite).

8.     Tests can be remotely or self-administered

  1. Plug-in certification is driven by Tempest self-certification model.
  2. Self-certifiers are required to publish their results.
  3. Self-certifier are also required to publish enough information that a third party could build the reference implementation to pass the tests.
  4. Self-certifiers must include the operating systems that have been certified.
  5. It is preferred for self-certified implementations to refer back to an OpenStack reference architecture “flavor” instead of defining their own reference (a way to publish and agree on flavors is needed).
  6. The Foundation needs to define a mechanism of dispute resolution (i.e. a trust but verify model).
  7. All ecosystem partners need to make a “works against OpenStack” statement that is supportable.
  8. An API consumer can claim working against the OpenStack API if it works against any implementation passing all the “must have” tests.
  9. API consumers can state they are working against the OpenStack API with some “may have” items as requirements.
  10. API consumers are expected to write tests that validate their required behaviors (submitted as “may have” tests)

9.     A subset of tests are chosen by the Foundation as “must-pass”

  1. An OpenStack body will recommend which tests are elevated from “may-have” to “must-have.”
  2. The selection of “must-pass” tests should be based on quantifiable information when possible.
  3. Must-pass tests should be selected from the existing body of may-pass tests.  This encourages people to write tests for cases they want supported.
  4. We will have a process by which tests are elevated from “may” to “must” lists.
  5. Essentially, the hope is that the User Committee will nominate tests that elevate to the Board.

10.  OpenStack core means passing all “must-pass” tests

  1. The OpenStack Board owns the responsibility to define core (to approve ‘musts’).
  2. We are NOT defining which items are on the list in the Spider effort; rather, just making the position that this is how we will define core.
  3. May-have tests include items in the integrated release, but which are not core.
  4. Must-haves must comply with the core criteria defined from the IncUp committee results.
  5. Projects in Incubation or pre-Incubation are not to be included in the “may” list.

For a quick visual way to understand how these position statements interconnect Rob posted, in his blog series, an ‘OpenStack Core flowchart’. [2]

Help Us Finalize the 10

These position statements are an ongoing work in process. It is our goal to finalize them for the November Board meeting and Hong Kong Summit. Yet in order to meet that goal, we want your help and, as such, would love to hear from you. I encourage you all to strike up a conversation on IRC with Rob, myself or any board member, or simply post your feedback to the Foundation mailing list. We’re looking to you to help us reach the goal of the Foundation’s mission!

Alan Clark
OpenStack Board Chair

[1] http://robhirschfeld.com/2013/07/23/introducing-the-openstack-spider-graph-untangling-our-web-of-interdependencies/
[2] http://robhirschfeld.com/2013/08/07/visualizing-the-openstack-core/