Ambassador Program – Specifics

 

August 27, 2013

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)

 

August 23, 2013

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/

OpenMic Spotlight: Gabriel Hurley

 

August 22, 2013

OpenMic_Gabriel HurleyThis 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. 

Gabriel Hurley is the Technical Lead for the User Experience team at Nebula Inc., PTL for the Horizon project, a member of Keystone core, and a core committer for the Django web framework. He has contributed to all the core OpenStack projects and developed numerous clients for interacting with OpenStack. His background is in web development and interface design, with a focus on Python and JavaScript development. Gabriel was first introduced to OpenStack while working at NASA, where his skills were immediately applicable to the nascent OpenStack dashboard project. Given his strong personal belief in open source this was a natural fit. Within six months he had moved to Nebula and began working full-time on OpenStack helping to build the future of this incredibly important endeavor. You can follow him on Twitter at @gabrielhurley.

1. Are there skills that you think are critical for OpenStack developers in the next 5 years? What specialties will be most useful? Valuable?

There are a few discrete layers of skills, and a few crosscutting talents. There will always be a need for people who understand the most fundamental layers: virtualization (flipping bits), storage systems (storing bits), and networking (moving bits). Those people will ensure that OpenStack gets faster and more resilient. There is also already an unmet need in OpenStack for people who craft great user experiences. In between are the folks who build the glue code and things like APIs that make it all hang together. In a more general way, OpenStack needs a pervasive awareness of a few key areas. Foremost, more people in the community need to have a basic understanding of security. This is the hardest job in Open Source, because as a security person you normally think in terms of attack vectors, audits and reviews. In Open Source a security person needs to spend as much time or more educating other people, because the best security comes from having the people who write the code in the first place be aware of the implications of what they’re writing. The most insidious security holes are buried in otherwise innocuous code, introduced by someone who simply didn’t know any better. Even worse is when a community embraces a practice that actively increases vulnerability (I’m looking at you, Rails…). Secondary to that, OpenStack needs its developers to be more aware of their end users. This shows up most prevalently in the APIs (which are often downright painful), but it also appears in configuration, deployment, and lots of other places. If every developer stopped for 5 minutes and thought about how someone else would use the code they’re writing a few months from now we’d have a much more functional OpenStack. So much of it has been written by people who had their use case in mind. We’re getting better about this as the community grows, but there’s still a lot of room left for more focus on the users.

2. If you could start your career over again, where would you want to begin? Advice for someone just getting started?

Quite honestly, I think my career’s had a fantastic trajectory. I could only wish I’d gotten started sooner. Everything good that’s come to me professionally is because I got involved in Open Source early in my career, I gave it my all, and I learned from fantastic people. Aside from all the magnificent developers in the Python and Django communities, I can’t stress enough how much I learned about leadership in an Open Source community and how crucial that aspect is. OpenStack still has a long ways to go in that regard. But my advice to anyone just getting started is to get involved with Open Source. Why? There’s no barrier to entry; you can do it RIGHT NOW! (I won’t be offended if you stop reading to go start contributing.) You can pick a project you actually use and care about. You will learn from people much smarter than you. You will be exposed to ideas you wouldn’t have ever considered. Still not convinced? How about the fact that Open Source is getting higher profile by the day?Recruiters look at GitHub profiles. Top companies hire talent based on their Open Source contributions alone. It gets your name out there forever and ever in a way that working for a private company almost never will. Need more? How about the fact that the work you do in Open Source immediately benefits people around the world. You’re actively helping people you’ve never met or heard of. I don’t know about you, but all those things make me feel pretty good at the end of the day.

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

If you couldn’t already tell, I’ve been involved with Open Source my entire engineering career; I’m a huge advocate for Open Source. Let’s imagine for a moment that one company could somehow amass such a staggering sum of money that they could hire all the talent that contributes to an Open Source project. And then that they devoted the time of all that talent to a single project. You still wouldn’t achieve the outcome of Open Source because you’d be lacking the conflict of different ideas, different goals, and different needs that drives innovation. And that’s with one company bearing all the burden! Let’s look at Open Source in practice in OpenStack: you have a collection of contributors, many working for competing companies. No one individally bears the burden of cost or development time (opportunity cost). Outcomes are improved by the tensions between different groups being forced to arrive at consensus. Features no one else would have thought of are brought forward because someone somewhere wanted to do something a little different. OpenStack works because ultimately it becomes a shared common good. Companies who would gladly obliterate one another are willing to work together because they all recognize that the financial gain isn’t in the platform itself; it’s in what you do with it. We’re all working towards a future where the infrstructure layer is a given. Compute and storage will be ubiquitous, you won’t think about it any more than you think about water coming out of your faucet. Sure, people make money for getting the water to you, but that pales in comparison to the value of agriculture, sanitation, living in previously uninhabitable places… This is the power of a shared interest in a common good, and this is the similar power of Open Source.

4. How do you think the OpenStack community will need to evolve over the next few years in light of the fast growth and maturing user needs?

OpenStack has to learn to function as a concerted whole rather than a collection of autonomous software projects. There is absolutely nothing that would make a bigger difference to users than that. We need consistency and unification in every area: clients, APIs, configuration, deployment, discoverability, federation… the list goes on and on. Up until now OpenStack has been governed by the whims of individual Projects and the frustration experienced by users, deployers, and even developers is obvious. It’s time for OpenStack to develop a stronger sense of cross-project leadership. All the features in the world are nothing if using them is an uphill battle.

5. What other open sources projects do you think work well with OpenStack, and why?

While you can deploy just about any open source application on top of OpenStack, I’m much more excited for the possibilities that projects like Docker (https://github.com/dotcloud/docker) bring to the table. Finding new ways to define and deploy distributed applications is what’s really going to fuel the “Big Data” revolution. OpenStack gives everyone access to the cloud, but once you have a cloud what will you do with it? We need tools that are human-friendly, reusable and remixable; getting your app running should be downright obvious. The secret sauce shouldn’t be in your deployment, it should be in your data and how you make meaning from it. The more we can get to that last step, the more we can change the world. One other open source project that deserves mention is Zipkin (http://twitter.github.io/zipkin/) which was released by Twitter. It’s a distributed tracing engine that allows you to follow one entry point (like an API call) throughout an entire distributed system and to understand exactly what it did at every step of the way. To get to the next level of optimization and unification OpenStack is going to need something like this built in. Trying to understand the complexity of an OpenStack deployment without distributed tracing is an exercise in agony.

Tags:

Introducing the OpenStack Ambassador Program

 

August 19, 2013

I’m excited to start 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.

Why we’re doing this

OpenStack is one of the fastest-growing open source projects and communities in history. We are fortunate to have more than fifty user groups globally and many passionate community members who are already making a big impact. 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.
In addition, the Foundation has become aware that there’s a need to improve the relationship between user groups and itself – allowing everyone to feel like they’re part of a globally connected community. For example, many of you who’ve been to user group meetups have probably heard feedback from people trying to deploy OpenStack – it would be excellent to aggregate this feedback from every group to help make our software and community better.

How will this work? 

We aim to select – initially – a small number of OpenStack Ambassadors, asking volunteers who are already respected members of our communities to be the primary point of contact in a particular region.
What will the ambassadors do?
  • Act as a liason between user groups, the Foundation, and the general community, for example:
  • helping to solicit feedback on OpenStack and aggregate it to the global level
  • promoting key messages into the user communities (eg “ask questions on ask.openstack.org!”)
  • finding people to help localise content
  • helping onboard new users and contributors
  • Assist in user group best practice – from nurturing new groups to cementing the quality of existing ones
  • Help people find the ‘right people’ to talk to
  • Represent the community via speaking and visibility opportunities with the official title
  • Report on the activities in their region
  • Be a good leader, wranging activity from others and mobilising the global OpenStack community!

Who will the Ambassadors be?

The title is designed to recognise those who are already good leaders with a proven track record in the community. With the title, new users, contributors and community members should easily be able to recognize their Ambassador as a go-to resource. While the role provides inherent credibility, it also comes with accountability, meaning decisions and actions made by the Ambassador should benefit the whole community, not just one person or company.
We believe that the Ambassadors will already be active participants in our community. Think about those people who are already working across multiple user groups, submitting OpenStack mini-events to related conferences, helping onboard new users and contributors, arranging hackfests or just generally going above and beyond in the name of making Openstack great.
To that end, we intend to ask that potential ambassadors provide some information about themselves, namely:
  • Why are you applying to become an OpenStack Ambassador?
  • How have you participated in the OpenStack Community to date?
  • What ideas do you have for your community, that you wish you had time or resources to implement?
A small number of ambassadors will then be selected based on a set of criteria:
  • Community participation track record
  • Geographical location
  • Potential impact of selection on community

 

Your feedback would be excellent! Please leave a reply below. Also: for more specifics on the program, and information about becoming an ambassador, see the next post.

Voting is Open – Help Choose Who Will Speak at the Next Summit!

 

August 15, 2013

Which speakers would you like to see at the next Summit?  It’s time to vote!

We’ve received a record breaking 600+ speaking submissions for the Summit in Hong Kong – more than double the quantity of submissions received for the Portland Summit!

Now it’s time to vote!  We’d like your help shaping the agenda for the next OpenStack Summit, November 5-8 in Hong Kong, by rating the submissions you’d like to see.  We’ve made all 600+ submissions public for your input.  You have until Sunday, August 25 at 22:00 UTC to vote up your favorites.

VOTE HERE 

Our voting interface is designed for easy use via mobile devices so you can continue selecting your favorites when you’re on the go.  Please note that you need to create login credentials in order to access the voting system.

While the Design Summit and more technical content will run Tuesday – Friday, the General Session track and keynote presentations will be Tuesday and Wednesday. We’re hoping to have the agenda locked and published by the end of September, but in the meantime you can see a preview of the agenda here.

A big thank you to our Summit sponsors for their continued support of the OpenStack community. See our current list of sponsors here.  If you are interested in sponsoring the summit as well, it’s not too late. Please email [email protected] no later than September 20.

Early Bird Registration closes October 4, so register now for discounted rates.   We also encourage you to book your travel now – hotel rooms are going fast.  Our block at the SkyCity Marriot has already sold out, but we still have room block availablility at Novotel and Regal, near Asia World-Expo where the Summit will take place.

Only three short months before we kick off the next OpenStack Summit, and we look forward to seeing you in Hong Kong!

OpenMic Spotlight: Kyle Mestery

 

minneapolis portrait photography, Twin Cities family portraits, St. Paul photography-20This 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. 

Kyle Mestery is a Principal Engineer in the Office of the Cloud CTO at Cisco. Kyle is the Chief Architect for Cisco’s OpenStack development, and has been actively participating in OpenStack and Open Source development for many years. Kyle has over 15 years of experience in systems software development ranging from distributed filesystems to distributed virtual switches. He is also an active speaker at Open Source conferences, and is the founder of the Minnesota OpenStack Meetup. In addition to being an active contributor to OpenStack, Kyle is also an active contributor to Open vSwitch and libvirt. His current focus in OpenStack is the Modular Layer 2 Plugin, where he is working to ensure ML2 will work successfully with the Open vSwitch and Linux Bridge agents, as well as with a new OpenDaylight Mechanism Driver under development. Kyle lives in Minnesota with his wife and 3 wonderful kids, who have all been exposed to programming through Ruby for Kids. Follow Kyle on Twitter at @mestery.

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

I think the main benefit from open, community-driven development is the fact you feel like you belong to something throughout the entire process. Participating in the development of something like OpenStack means you are working with a large number of people spanning the entire globe. And the first you’ll notice is the sense of community one feels when doing this sort of development. The learning process you go through when getting your first commit may be a little steep, but once you’ve gone through it you’ll find you’ve made new connections from the people who assisted you along the way. And once you’ve made more than a handful of commits, you’ll be able to switch around and help other people make their first commit.

In addition, open development means everything is done in the open. From the initial design of a feature, to the development of the feature, to it’s eventual inclusion into the source tree and it’s documentation, all of this is done in the open. This means anyone can comment and contribute along the way. And this is what makes Open Source development so powerful. Open development and Open Source level the playing field and allow a much broader scope of people to become involved at every step of the process.

2) What are the essentials for someone just getting started with OpenStack? Sites? Books? Conferences? People?

When you’re just getting started with OpenStack development and you’ve never used git, gerrit, and other open source tooling technologies, the task can be somewhat daunting. Colin McNamara has put together a great presentation which covers “How To Survive Your First OpenStack Checkin”. He’s given this talk at the last two OpenStack Conferences, and it’s a great talk for someone beginning their OpenStack development journey. I highly recommend new developers to OpenStack to have a look at Colin’s slides:

http://www.slideshare.net/colinmcnamara1/open-stack-summit-surviving-your-first-checkin

Another great resource for someone just getting started with OpenStack are local User groups. One of the great things about OpenStack is the community of people who exist inside the ecosystem. There are User groups everywhere, and there is likely one close to where you live. Joining your local User group is a great way to get to know people using and developing OpenStack who live close to you. You’ll find a local community where you can share ideas and learn from others.  And if there isn’t a local User group near you, why not start your own?

https://wiki.openstack.org/wiki/OpenStack_User_Groups

Another critical resource for people new to OpenStack is IRC. IRC, for those new to it, stands for Internet Relay Chat, and is a way the majority of developers and users in the OpenStack community communicate with each other. There are IRC channels covering many sub topics of OpenStack, joining the appropriate one is a great way to ask questions as a user or a developer. You’ll find core developers for each of the OpenStack project are always on IRC and are willing to help.

https://wiki.openstack.org/wiki/IRC

3) What other open sources projects do you think work well with OpenStack, and why?

The list of Open Source projects which work well together with OpenStack is quite large. I’ll focus on a few which I’m familiar with and actively am involved with:

Open vSwitch is an Open Source virtual switch, originally developed by Nicira, now VMware. Open vSwitch has a large number of contributors, and is the base virtual switch for a large number of OpenStack Neutron plugins. The fact so many Neutron plugins rely on Open vSwitch running on each host makes it a core component of most OpenStack deployments.

libvirt is a library for managing and running virtual machines. libvirt supports a large number of hypervisors, and is a critical component of most KVM-based Linux hypervisor deployments. In OpenStack, when you run with KVM hypervisors you are using libvirt to run virtual machines on compute hosts. libvirt integrates nicely with OpenStack Nova to handle this, and is a critical component of OpenStack deployments with KVM.

Ryu is an Open Source component-based Software Defined Networking framework. Ryu is modular and supports a large number of protocols underneath. Since the Folsom release of OpenStack, Ryu has been an optional plugin for OpenStack Neutron. The flexibility of Ryu makes it an interesting choice for Elastic Cloud Platforms when deploying OpenStack.

OpenDaylight is an Open Source Software Defined Networking Controller sponsored by the Linux Foundation and developed by many different companies and individuals. OpenDaylight is a relatively new Open Source project, but the momentum behind it has been amazing to watch over the last 6 months. Work is currently underway to develop an OpenStack Neutron Modular Layer 2 MechanismDriver for OpenDaylight, with the hope of this becoming the reference controller MechanismDriver for ML2.

4) How would you suggest to someone that they should pick OpenStack for deployment? What is the most compelling argument for OpenStack in your mind?

OpenStack is a great deployment option if you’re looking for an Elastic Cloud Platform and you want to take advantage of the things a platform like that can provide. If you’re looking to deploy something along the lines of Amazon Web Services in your own lab or datacenter, OpenStack is a great choice. The scalability and flexibility provided by OpenStack map perfectly into this use case. And if you are already familiar with Amazon Web Services, deploying OpenStack into your own datacenter will provide you with familiar functionality for your local tenants and users.

Another great reason to pick OpenStack is if you’re looking at deploying your own Platform as a Service. Anyone looking to deploy something like OpenShift Agile or CloudFoundry should look seriously at how they can deploy those items on top of OpenStack. Someone looking to deploy Hadoop in an Elastic Cloud Platform should look at OpenStack as the underlying cloud platform for their Hadoop deployment. These are examples of strong use cases for applications deployed on top of OpenStack. And when you start to think in terms of scalability, flexibility, and manageability at the application level, OpenStack becomes a compelling option.

The most compelling argument for deploying OpenStack is the fact it allows you to unlock the power of your applications and run them in a truly elastic fashion on top. Once you start to think outside of the typical enterprise computing box, you realize how powerful this can become. And when you start to think in terms of elastic computing and computing on demand, deploying OpenStack becomes even more compelling. The simplicity and scalability of OpenStack makes it a compelling deployment option for anyone looking to deploy any type of cloud computing setup.

5) What is the most common misconception you hear about OpenStack? 

The most common misconception I hear about OpenStack currently is the fact people new to OpenStack think it’s an enterprise virtualization platform which is a replacement for vSphere. In my opinion, this is a rather limiting view of OpenStack, and doesn’t take into account what OpenStack was designed to be. OpenStack was designed to be an Elastic Cloud Platform more in line with what Amazon Web Services is. Trying to box OpenStack into being a replacement for something like vSphere limits the true power of OpenStack. This common misconception comes from enterprise users and developers who have years of experience with vSphere. It’s true that OpenStack is slowly developing features which put it more in line with an enterprise virtualization platform. But it’s more interesting to think outside of that box and imagine what you can do with a truly Elastic Cloud Platform. Once you do that, the possibilities you open are amazing. Thinking in terms of application scalability opens up new doors where you are no longer limited by hardware, but are more in tune with what the software can provide you and what you can do with the software you develop and/or run on top of OpenStack.

Tags:

OpenStack Community Weekly Newsletter (Aug 2-9)

 

August 9, 2013

Hong Kong Summit – Registration, Call for Sponsors Now Open!
在全体大会中将提供英文至中文之即时翻译。 要得到更多信息， 请查阅注册信息页

DevStack in 1 minute

It can be as easy as it looks: step by step instructions by Sébastien Han.

OpenStack Compute For vSphere Admins

An ongoing series of posts by Kenneth Hui about OpenStack for vSphere Admins.  You can catch up on previous posts by following the links here for part 1, part 2, part 3 and part 4.

OpenStack’s Test Driven Core

In helping drive OpenStack’s “what is core” dialog, board member Rob Hirschfeld has reported a lot of viewpoints about what OpenStack is and what it should be. As a good steward of this process he has successfully managed to be an objective listener.  In the recent post in the series, he expresses his point of view. This is one of the most important conversations for the OpenStack Foundation and it’s happening now.

Flavors – An English perspective

OpenStack has the capability to define flavors of virtual machines, how many cores, swap, disk and memory. As a native UK English speaker, Tim Bell finds the term flavor to already be a problem. In his post describing how flavors are used at CERN he appeals to the OpenStack technical committee to not accept any term which is not the same in US and UK English or to allow an alias. His post has lots of other interesting information, too.

Non-Relational Database-as-a-Service in OpenStack

The OpenStack Technical Committee voted this week to expand the scope of the Trove program, which is currently in incubation, to encompass non-relational as well as relational databases.

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!

  • Jing Sun, IBM
  • Zhi kun Liu, IBM
  • ZhiQiang Fan, None
  • raiesmh08, ?
  • Toni Zehnder, ZHAW ICCLab
  • Yijing Zhang, None
  • Roman Verchikov, Mirantis
  • Noorul Islam K M, None
  • Teran McKinney, Rackspace
  • Mark Collier, OpenStack Foundation
  • Deepti Navale, Red Hat
  • Tracy Jones, VMware
  • Joe H. Rahme, Enovance

OpenStack Reactions

tumblr_inline_mk6xomQvzf1qz4rgp.gif.pagespeed.ce.atu8tnp8ox

Trying to get your code pep8+hacking violation free.

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: Brad Topol

 

August 8, 2013

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

Brad Topol is an IBM Distinguished Engineer in the Software Group Standards Strategy organization. In his current role, Brad leads a development team focused on contributing to and improving OpenStack.  In addition to leading a team, Brad has also personally contributed to multiple OpenStack projects including Keystone and DevStack. Prior to his current role, Brad was  IBM Distinguished Engineer, SWG Serviceability, with responsibility for driving IBM software group’s cross-product serviceability and electronic fix distribution initiatives. Over the years, Brad has been involved in advanced technology projects in the areas of product serviceability, problem determination, autonomic computing, content transcoding for mobile devices, and Web Services.  In 2000, he received an IBM Outstanding Technical Achievement Award for contributions to the IBM WebSphere Transcoding Publisher product.  He received a Ph.D. in Computer Science from the Georgia Institute of Technology in 1998. You can follow Brad on Twitter at @bradtopol.

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

When not working on OpenStack,  I am typically either working out at the gym, helping kids with homework, or taking the kids to softball practice, baseball practice, soccer practice, and flute lessons.

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

The first commit that I made was to fix a Glance registry documentation paste.ini sample that was missing a configuration section for using an authtoken filter. I made this change because I wanted to fix a simple bug that would enable me to learn the OpenStack process for making contributions via Git and Gerrit.

3. Are there any skills that you think are critical for OpenStack developers in the next 5 years? What specialties will be most useful? Valuable?

A key critical skill for an OpenStack developer is to have an extremely strong understanding of the Python programming language and its advanced features. So many of its advanced features are used throughout the OpenStack projects and I’m sure this will continue as Python evolves. The most important skill for an OpenStack developer, however, is to not get complacent once they become an expert on one portion of OpenStack. For example, someone may become an expert in Nova and then their job becomes easy. They know how to perform quality reviews quickly and can make contributions quickly and can go on cruise control a little. When a developer hits this point I strongly recommend that they force themselves to get out of their comfort zone and spend some time learning a different portion of OpenStack. This will be hard, and they may hate being the rookie “dumb” guy in the new project. Nonetheless, the result of them pushing themselves to learn something new will ensure that they continue to improve their skills, enable them to drive greater innovation, and will accelerate their career growth and development.

4. What is the most important contribution you’ve made that will make OpenStack users happy?

The most important contribution that I have made to OpenStack that will make OpenStack users happy was adding Transport Layer Security (TLS) support to Keystone’s LDAP identity backend. This enabled Keystone to have an optional secure connection when using LDAP or Active Directory as its backend identity store. What was great about this contribution was that I have been on customer calls where the customer explicitly asked if Keystone had TLS support and it was really cool being able to tell them that yes it does and also that I personally implemented it!

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

There are so many benefits of the open, community-driven approach to development. First, the diversity of having developers from companies all over the world results in solutions to problems being identified quickly and best of breed continuous integration development practices being utilized. As a result, development in an open, community-driven approach occurs at lightning speed. Furthermore, the peer review process utilized for every code commit results in a very high quality code base. I know many times I would think to myself that my patch was “good enough” but then my peers would review it and convince me it most certainly could be better.   This peer pressure motivated me to deliver higher quality code than what I would have normally delivered had I not been subjected to peer review. Another benefit is that when you run into a problem that you can’t resolve on your own you can then go ask the community. Most of the time there will be someone in the community that has already encountered the same problem and you will be able to solve the problem much faster than just working on the issue in a vacuum. A final benefit of the open, community-driven approach to development is that open communities breed strong ecosystems.  These strong ecosystems increase the longevity of the community and this improves the confidence the user base has with the the community software.

Tags: