The OpenStack Blog

Category: Development

Lessons, Learning, and Long Views for Internship Programs

In January 2013 the OpenStack project welcomed aboard three interns and excitedly assigned them to work on fairly complex projects in our first attempt at an organized project-level internship program. The OpenStack Foundation participated as one of the organizations with the GNOME Outreach Program for Women and learned quite a few lessons during the six months internship period.

By February, two of the interns had learned the tough lesson of what happens when coordinated work efforts move at a fast pace. For example, Laura Alves, an API documentation intern had a patch with a manually created WADL for the Networking project nearly completed. She started requesting reviews from the core developers. We soon discovered that the devs were working on an automated method for creating the WADL. It certainly took some quick communication and coordination to make sure her work wasn’t wasted. Her efforts certainly weren’t wasted but it also hasn’t landed quite yet either. Lesson learned: internship projects are difficult to scope and it’s nearly impossible to set aside tasks in a reserve area just for interns.

Still more lessons learned were that the timing of code freeze dates landing prior to the internship’s completion made for a steep on ramp for new interns with early deadlines. We also found that interns can contribute so much right away with their fresh perspective — and they created such valuable blog entries for newcomers, like Logging and debugging in OpenStack by Victoria Martínez de la Cruz,  so they’ll be helping more newcomers for months.  We pulled all our lessons learned together for a “What Everyone Should Know About OpenStack Internships” panel session at the Summit in Portland.

One of the takeaways from the Summit was to learn more about mentoring from Katy Dickinson, and the blog at MentorCloud where she is Vice President has been very valuable to learn from as we continue to shape our plans for interns wanting to learn and contribute to OpenStack. Katy attended our brainstorming session at the Summit and gave us very useful suggestions. We surveyed outgoing interns and are working on a plan to coordinate early and often to identify and promote natural mentors in the OpenStack community.

The more you look for internships and mentors in OpenStack, the more you’ll find. Cisco has interns working on OpenStack projects each summer. One OpenStack intern, Emilien Macchi, at StackOps went on to do a graduate part-time internship at eNovance. Rackspace has interns working on multiple OpenStack projects.

The Foundation is continuing the involvement in the Outreach Program for Women also in the northern hemisphere’s summer edition: Terri Yu started working on the Ceilometer project with Juilan Danjou at the end of May: be sure to welcome her! Look for more opportunities to connect the dots with interns and mentors in the coming months. If you have funds for travel so interns and mentors can meet each other in person, let Stefano Maffuli know. If you have a great intern story to tell, please let us all know.

New Foundation Gold Members & Corporate Sponsors

The OpenStack Foundation was thrilled to add two new Gold Members and 13 corporate sponsors so far this year to the already impressive list of companies who are supporting the Foundation and driving innovation on the platform.    Ericsson and Juniper Networks won the OpenStack Board’s approval at the April board meeting and joined the Foundation as Gold members.  To learn more about these companies and their OpenStack initiatives please visit and

We’ve also seen amazing support in Corporate Sponsorship and we want to share the impressive list of recent additions.

The diversity in technologies and geographic location of these new additions to the ecosystem reflects the growth of OpenStack and its footprint worldwide.  We are looking forward to enjoying each these companies’ unique contributions going forward!

An introductory tour of OpenStack Cloud Messaging as a Service

Post by Mark Atwood, Director of OpenSource Engineering for HP Cloud


The need for well understood intra-application messaging was one of the signs that new application design patterns beyond just the LAMP stack were needed.

The need for an OpenStack Messaging Service was recognized by the San Diego Grizzly Summit, and in an unconference track design meeting on the last day, a crowd of interested people met, talked out some requirements, and from that the OpenStack Message Bus project was born. It was codenamed “Marconi”, in honor of Guglielmo Marconi, the inventor of wireless messaging. The Marconi team collaborates on Launchpad.

At the same time, HP was looking for a way to make it’s already under development application messaging service available to users of the HP Cloud. When the Marconi project appeared, HP decided that instead of splitting the developer community in a pointless API standards war, it made more sense to clone and track the public Marconi API, and then contribute to open source Marconi project itself.

As part of the development process, HP is running the messaging service in “developer preview”, meaning that you have to ask to be enrolled in the preview program to access it, and neither the service nor the API are stable. Oh, and right now it is free of charge.

Log into your HP Cloud account, and then go to the URL and look for “Beta Services” and then “Request Access” to “Messaging”. Your request will be reviewed, and then activated. This can potentially take a couple of days, because there are human beings in this decision loop.

All parts of OpenStack and HP Cloud are controlled via RESTful APIs, and Messaging is no exception. We will access the raw API with the cURL command line tool. Using a specialized client tool can be simpler to use, and such tools are under development. However, walking this process step by step the first time helps build an understand of how all the parts work.

First thing we need is the API credentials to your HP Cloud account.

After logging into your HP Cloud account, go to the URL and look for following information:

  • “Project ID”, something like “58345815996918″
  • “Access Key #1″, something like “2DJ3Z58RZB5JJ7V2JKS3″
  • “Show Secret Key”. When you click on it, it will reveal something like “bPH13haenb/DlvR1th+u4Uj5ehvYKsF7ApYact6i”
  • The URL for “Identity” “region-a.geo-1″. It will be something like
  • The URL for “Messaging” “region-a.geo-1″. It will be something like

Now open a text editor, and construct a file named keystone-req.json with JSON contents like the following, only with your own access key, secret key, and tenant id (aka “project id”).

"auth": {
"apiAccessKeyCredentials": {
"accessKey": "2DJ3Z58RZB5JJ7V2JKS3",
"secretKey": "bPH13haenb/DlvR1th+u4Uj5ehvYKsF7ApYact6i"
"tenantId": "58345815996918"

Now, at the command prompt, run the following cURL command. Notice that the URL is the one for “Identity” “region-a.geo-1″ we looked up earlier, with the path part “/tokens” appended to it.

curl -X POST -H "Content-Type: application/json" \ \
-d @keystone-req.json \
| python -mjson.tool > keystone-rsp.json
Notice that we pipe the output through "python -mjson.tool". This is a useful trick for prettyprinting JSON to make it more readable.

Open up the resulting file keystone-rsp.json in a text editor, and take a look.

Search down for the string “token”, and you should see something lilke

"token": {
"expires": "2013-05-21T12:38:16.962Z",
"id": "HPAuth10_3e1c44e527f0e64387ff0705e1b09d0ca3ef47c47a6c6afe1738d77f896b4f20",
"tenant": {
"id": "58345815996918",
"name": "[email protected]"

The important part is the “” value. We are going to paste that string into the HTTP X-Auth header for the next few cURL commands.

Now search the file for the string “hpext:messaging”, and you will find a block of JSON that looks like this:

"endpoints": [
"publicURL": "",
"publicURL2": "",
"region": "region-a.geo-1",
"tenantId": "58345815996918",
"versionId": "1.1",
"versionInfo": "",
"versionList": ""
"name": "Messaging",
"type": "hpext:messaging"

The “publicURL” is the URL we can use to issue REST commands to the Messaging service. Here is how we list all the queues we can use. Notice that we pass the keystone authentication token in on the X-Auth-Token header.

curl -X GET -H "Content-Type: application/json" \
-H "X-Auth-Token: HPAuth10_3e1c44e527f0e64387ff0705e1b09d0ca3ef47c47a6c6afe1738d77f896b4f20" \ \
| python -mjson.tool

We will probably see

"queues": []

which means, logically enough, no queues have been created.

Let’s create one. We change the method to PUT and append queues/foo to create a queue named “foo”. There is no need to use the JSON prettyprinter, because no request body will be returned.

curl -X PUT -H "Content-Type: application/json" \
-H "X-Auth-Token: HPAuth10_3e1c44e527f0e64387ff0705e1b09d0ca3ef47c47a6c6afe1738d77f896b4f20" \

And then let’s again list all the queues.

curl -X GET -H "Content-Type: application/json" \
-H "X-Auth-Token: HPAuth10_3e1c44e527f0e64387ff0705e1b09d0ca3ef47c47a6c6afe1738d77f896b4f20" \ \
| python -mjson.tool

which returns

"queues": [
"name": "foo"

Look at that that! A queue named foo.

Now let’s put something on that foo queue. We do that by POSTing some JSON to the queue URL with the path part “/messages” appended, like so:

curl -X POST -H "Content-Type: application/json" \
-H "X-Auth-Token: HPAuth10_3e1c44e527f0e64387ff0705e1b09d0ca3ef47c47a6c6afe1738d77f896b4f20" \ \
-d '{ "body": "Hello World!" }'

And then read it back.

curl -X GET -H "Content-Type: application/json" \
-H "X-Auth-Token: HPAuth10_3e1c44e527f0e64387ff0705e1b09d0ca3ef47c47a6c6afe1738d77f896b4f20" \

which will remove the item and display

{"id":"b41ea44e-3962-4010-80ad-4f87dcd6ba8d","body":"Hello World!"}
And then let’s delete the queue

curl -X DELETE \
-H "X-Auth-Token: HPAuth10_3e1c44e527f0e64387ff0705e1b09d0ca3ef47c47a6c6afe1738d77f896b4f20" \

As always, if you have any questions, send us an email. You can contact me directly at [email protected]


Discussions at Breakfast with the Board – OpenStack April 2013 Summit

It is an exciting time to be part of the OpenStack community.  It was a great conference with lots of momentum around OpenStack.  The speed and growth of the community is amazing.

Tuesday morning during the Summit, we continued the tradition of Breakfast With The Board (BwtB).  We wish to thank all who participated.  As board members we very much appreciated your comments of support, feedback and ideas.  We heard many positive and encouraging comments  and participated in many lively discussions.

Through this writeup we would like to share what we heard.   There was a wide variety of topics discussed, including:

Summit Design Session Growing Pains
Despite a variety of changes tested and introduced over the past Summits, accommodating all who wish to participate in the Summit design sessions continue to exhibit growing pains.  The design sessions are “intended to be small, focused developer working sessions where the roadmap is set by active contributors on the project.”  With such a description it is easy to see why so many business persons, users, and developers want to participate or listen in. Yet the fear is that a varied large audience will decrease session output.

Many ideas were voiced at the BwtB as to how to address the issue, including room moderators, attendee prioritization, seating arrangements and session segregation.

“Scotty we need more power er WIFI”
While the conference survey will prioritize on  what items will be most relevant to improve for the next Summit, one of the vocal suggestion at the BwtB was the never ending need for more WIFI.  We techies live on WIFI.

Who the heck is…
Leading the list for reasons to attend the Summit is to simply meet people we work with on IRC and other community channels.  A simple suggestion was made that we add IRC nicks in a nice big font to the front and back of the conference badges. 50% of the time you see the back of someone’s badge and don’t know who they are.

Traveling to the Fall Summit
For those traveling to the fall Summit from the North America, concerns over prohibitive travel costs was raised.  Determining a Summit location is made up of many different factors.  Cost of travel being one.    A Summit location effects attendance, whether it be in Portland or Hong Kong.  Balancing that cost can be tricky.   The planning committee investigations concluded that attendees will find that the travel rates will not be the feared prohibitive if they do some research and book early.

Driving Priorities
Several discussions evolved around the idea of how customer priorities are injected into each projects focus and features. Typically in a corporate development model such interests are captured and formulated into the development model through Product Owners (PO) or Product Managers (PM).  How does this map to the OpenStack model?  Which is easily generalized to how does this map to the open source world?

At the BwtB, several of the discussions converged on the notion of contribution.  Contribution either in the form of code, leadership or voice.  One company simply cannot pretend to make choices for resources in another company. At most you can find other resources from a  company which share a problem you are helping describe and therefore solve.

A familiar saying in the open source world is “scratch the itch”.  It is this saying which has driven open source developers for years.  If you find a need that nothing out there can meet, write a solution yourself or better yet voice the need to help find those who share in the need and write a solution together contributing in ways that leverage your experience and expertise or providing support to those who can contribute for you.

Big Vision
Also discussed at the BwtB was the notion of having the TC play more of a role across the various projects, for things like security and API versioning, aligning and setting direction across the groups. Citing the need for the TC (or someone at least) to give more cross project consideration for:
API compatibility and consistency
architectural consistency
Input from Users to guide our path

Align the Doc
Opinions voiced concerns that the documentation lags the implementations.  So how do we  make the OpenStack documentation more up-to-date and improve quality and timelines?  That was the question raised by attendees at the BwtB.  Offered suggestions included a requirement for documentation changes to be checked in concurrent with the code, rather than just setting a flag that the doc’s might be effected.

What comprises OpenStack?
A couple of tables discussed the current progress around the current Core/Integrated/Incubated framework with input on moving forward; people seem to prefer the kernel/drivers analogy. There is confusion regarding the new approach to core-integrated-incubation,  what the differences are, who gets seats on the TC, etc.  Early and continued discussions at Technical Committee and Board on this are important for next phases of the effort. It is important  to ensure that the TC and Board sign off on all steps with formal statements by the foundation when we arrive at any and all conclusions.

There is a lot of interop interest. Folks at the BwtB seemed to be mostly happy with the refstack approach. They voiced opinions about whether API-based interop or same-codebase interop is appropriate in various projects and for having verification teams for plug-ins.

Marketing OpenStack
Where does OpenStack as the data center operating system model go?  How to support that?  Marketing discussions ranged across several of the tables.  Including a conversation at one of the tables  on how to best explain OpenStack to CIO/IT Directors. Participants in the discussion felt that the video overviews available on the OpenStack website as well as the user stories presented at the Summit Keynotes were of great help.

Others pondered why FUD is generated by open source competition with a  lack of sense of those for who their competition really should be (proprietary software).

And others voiced concern over perceptions around OpenStack.  These perceptions include, complexity, talent shortages, security gaps and that it takes too many people to run OpenStack.  Such perceptions create a barrier to adoption.

The Board at its February meeting, launch a committee to improve transparency and foster collaboration between the foundation members and members of the board, technical committee, user committee and other committees.  Members of the committee took the opportunity to discuss, at their tables, the committee ideas and efforts.  Everyone is all for transparency and seeking a balance between transparency and compromising the strategic position of the project was accepted as an important consideration. The ombudsman and staggered release were seen as valid solutions.

Attendees also voiced the importance for direct participation within project processes.  It is important that the TC and board to listen to what the project have to say.

The Board at its February meeting also launched an effort to improve the Individual member election process.  The board members engaged in this effort took the opportunity to gather feedback at the BwtB on the ideas and efforts underway.  Many were pleased that a schedule for implementation of changes is being set and were pleased with the efforts so far.

As you can see there was a wide range of topics raised and discussed.  Each of which could be worthy of a full writeup on its own. As a board we appreciate the input.  We will delve into the issues further and will use this input to guide the prioritization of our efforts.  So again thank you for your participation. We look forward to the next BwtB at the fall Summit.


OpenStack Board of Directors

Contribute to OpenStack Activity Board

We’ve released the complete documentation for OpenStack Insights, with binaries and source code downloadable from Sourceforge while the OpenStack Dash tools are the vanilla MetricsGrimoire set hosted on github. The code is free as in freedom so you’re welcome to play with it. We’re working to put both pieces of code in the hands of the OpenStack Infrastructure team soon.

Following up on the long session hosted during the  Summit in Portland and 1-on-1 discussions, I’ve created a new topic on the Development mailing list.  You can join the conversations about OpenStack metrics and the Activity Board  avoiding the high volume traffic on the Development list by subscribing only to the Metrics topic. You’ll receive only messages that have the words [metrics] or [activity] in the subject and nothing else.  Go to to subscribe and pick “Metrics” among the topic categories you would like to subscribe to.

If you want to know how the OpenStack Activity Board can help you understand your team’s activities in the project, build reports, integrate data from different sources, join the webinar we’re hosting on May 9th. We’ll keep ironing out the known issues while we think about the future of the platform.

Introducing the OpenStack Activity Board

I am pleased to announce that a beta release of the OpenStack Activity Board (beta) is now live. The development Activity Board announced few months ago provides a visual overview of all the OpenStack public activity of community members across multiple dimensions: contributors and organizations, projects and tools. From a single interface, you can easily surf OpenStack project content, whether it is coming from the LaunchPad bug tracker, Git or Gerrit, all mapped against the OpenStack Foundation members database.

The Vision Behind the Activity Board

The intention is to give the community a way to answer very precise questions like: who’s contributing to that particular feature of OpenStack? What is that developer/company working on? Which commits/changes are related to a particular bug? Who’s joined the development community recently? With the Activity Board, we have integrated information across the different systems used to develop OpenStack to give corporate and community users a unified view of all the efforts going into OpenStack. There are two main parts of the Activity Board: the Dash and the Insights. The Dash contains reports built by Bitergia using the free software suite MetricsGrimoire, it focuses on trends and quantitative presentation. The Insights, enriched with a semantic layer, powered by zAgile’s open source Wikidsmart adds qualitative details with faceted search of concepts across all the different repositories, tracing people and artifacts across different repositories and bug tracker in order to reconcile people and corresponding contributions.

Looking to the Future

With the integration, we know that we can become a much more efficient project in terms of communicating to members, monitoring our progress, and getting work done. The project is its infancy and we wish to continue to evolve the solution and enhance it with everyone’s feedback. First of all we need you to look at the data and let us know if you find any mistake (we’re keeping a log of known issues). There are a number of areas we want to consider, for example:

  • Streamline the faceted search interface according to the community’s desires
  • Add more reports based on community requests
  • Add integration with other OpenStack project data sources (blueprints, mailing lists, Ask, user groups, IRC)
  • Potentially enable interoperability (which is inherent in the Wikidsmart abilities) so that an event in one tool, for example LaunchPad, kicks off another action or update within another tool
  • Remove the dependency on Confluence, port the visualization to an open source wiki or portal,
  • Publish all the code and tools, integrate the Activity board in the OpenStack infrastructure processes

Learn More

If you would like to learn more, we are featuring the OpenStack Activity Board in the upcoming events:

I look forward to your comments and further collaboration to make sure this solution benefits the whole community to the maximum extent.

A Pretty Good Place to Be

One of the best things about my work with OpenStack is the excitement I get when I envision the impact the work we do here today will have on the IT departments of the (very near) future.

Imagine a stay in a hospital, where instead of of nurses and med techs coming in every four hours around the clock to monitor your vital signs, a small monitoring device with specific sensors sends a steady stream of medical information to a central monitoring station. Software at the station not only looks for large anomalies, but also innocuous patterns that could indicate something serious.

Or imagine that kind of medical data being delivered to a central monitor when the patient is in their home. Or at work.

Fill a city with climate and environmental sensors, like noise and light levels, and use those sensors to identify emergencies before someone can dial a phone or long-term problems about the health of a particular neighborhood.

Put some sensors in a farm field in a developing country, and let farmers use the gathered data to know exactly how much water and nutrients to use for different parts of the field. For pennies a sensor, the yield of the field is maximized to help support a family for another year and maybe bring a little extra to the market.

A train car that knows exactly where it is at any given moment, cutting down on waste and unexpected routings.

A smart home that can control temperature, ambient light, and even alert a parent when a toddler is opening a cabinet they are not supposed to be in.

These are all just a very few examples of what the media calls the Internet of Things, either very real or in development as you read this. If you look an an object and imagine what that object could do if it were connected to the Internet, you can think of cool new applications on your own.

“Internet of Things” is a romantic notion. It’s not like web servers and file servers were animate objects all this time. But  whatever you call it, this new interconnected network of everyday objects will greatly impact people all of the world.

You can be sure that entrepreneurs are thinking of creative new ways to plug more devices into the Internet of Things, and all of them will need the same thing: a safe, secure platform on which they can store the data they will gather and analyze it to deliver the key services they will provide. If that platform is highly configurable and open, so much the better to mesh the platform to their needs.

One of the many applications of OpenStack technology will be to build that platform, and be a part of a world that will talk to us and tell us how to take better care of ourselves.

And that’s a pretty good place to be.


OpenStack Outreach Program for Women Accepting Candidates

OpenStack provides open source software for building public and private clouds. We are constantly moving and growing and very excited to invite newcomers to our community. To this end, the OpenStack Foundation has joined the GNOME Outreach Program for Women.

The Women in OpenStack group has already found some mentors for the program and ideas for projects are flowing in. Each internship requires $5,000. We have funding from Rackspace and Red Hat for two participants, and the Foundation is also sponsoring one intern. More funding is welcomed.

Interns are expected to spend 40 hours a week on the project and applicants may not have ever worked on FLOSS before.


The program starts in November 2012 and the results of the internships will be ready by Spring 2013 OpenStack Summit.

  • November 14: program announced and application form made available
  • November 14 – December 3: applicants need to get in touch with at least one project and make a contribution to it
  • December 3: application deadline
  • December 11: accepted participants announced
  • January 2 – April 2: internship period
  • April 2013: OpenStack Summit

Five Outreach Program for Women interns from previous rounds – Liansu, Christy, Meg, Tamara, and Barbara – created this cartoon to explain the application process!

If you have a pet project and want to mentor new women members of OpenStack community please contact Stefano Maffulli or Anne Gentle, add your ideas to the wiki page, and discuss on the openstack-dev mailing list.

If you know of students who would be interested in these internship opportunities, help us spread the word by linking to this post and our wiki page about the program.

How Sina Contributes to OpenStack

OpenStack launches a new release every 6 months. Essex was released 6 months ago, and Folsom came out on September 27. Every release  is followed by a third-party report on the individual and corporate contributions. In this article,  I’d like to talk about how we Sina OpenStack dev team, as an important corporate contributor in OpenStack projects, involves in the OpenStack community and how we contribute to OpenStack Folsom ?

6 months ago, in a report of Who Wrote OpenStack Essex? by ReadWriteWeb, we were surprised to see that Sina was for the first  time listed among Top 10 bugfix companies, ranking #9. My team was highly inspired, and we never thought that our little work in OpenStack could be able to be listed along with the International IT giants, like Rackspace, RedHat, IBM and HP.  Since then, we have devoted much more weight on the community development of OpenStack official projects, and  invested more resources and encouraged all team members  to engage in OpenStack community development as well.

As a result, we have achieved much progress during Folsom release according to the statistics from openstack-gitdm, which is maintained by Mark McLoughlin, an OpenStack contributor from Red Hat,  and provides the contribution data extracted from git commits, Gerrit and launchpad for 7 core projects of OpenStack during the whole Folsom release.

In general, we have contributed 147 patches to the 7 core projects of OpenStack, ranking #4; having 74 bugfix been approved, also ranking #4;  11,787 lines of code been merged, ranking #8, and we have 18 stackers who have code contributions in Folsom release, ranking #2 after Rackspace.  Bitergia’s report on Folsom using different toolset and methodology also concludes the similar result.  (More statistical graphs are shown in the photo gallery bellow)

Moreover, we have been involved in the collaborative developments of all the 7 core projects, which means we have balanced investment in these projects, and we believe this strategy  will benefit us in better understanding the whole OpenStack frameworks and different components. If only counted by the number of patch, we ranked #6 in Nova, #3 in Quantum, #3 in Cinder, #6 in Glance, #3 in Keystone and #11 in Horizon.

But why, how and what did we Sina OpenStack team contribute to OpenStack community and OpenStack projects?

Why and How?

In the mid of 2011, when the Diablo release was under heavy development, we decided to use OpenStack as our underlying system of Sina IaaS public Cloud, Sina Web Services(SWS), and another strategic product besides Sina App Engine(SAE), which is developed by my former team members and already the most popular public PaaS cloud in China.  But then OpenStack was full of bugs, not very stable and not ready for production deployment, and also lacked  some essential components, such as billing, monitoring and load balancer etc. So we invested several engineers to do bugfix, to implement new features and to design necessary services. In the beginning, we forked an internal branch from a particular commit of OpenStack, and had much development on the internal branch. Later we found that it is a little difficult to merge upstream updates to our own branch, if this condition did continue, our project would be dangerous since it would go more and more far way from the official projects, and we would finally lose the community and the ecosystem. So we stopped the trend immediately and cut down our own fork. Instead, we joined the community, collaborated with gurus around the world, and combined the requirement of our own public cloud projects and need of OpenStack community, so that we could be able to avoid duplicated development, and it has become a win-win game for the community and my employer. In fact, we have contributed all our bugfixes and feature improvements to upstream. We also opened sourced our own implementation of  biling(Dough) and monitoring(Kanyun). We benefited a great deal from  this change.

First, most importantly, many of my team members have  grown up from a newbie to an experienced and qualified OpenStack contributor through the collaborative community development in a short time, thus in turn the progress of our own projects were speeded up  with such quick learners.

Second, by means of contributing our own feature implementations and open-sourcing additional projects, we got lots of valuable feedback from PTLs, core developers and the community, guiding us to better software design and  implementation.

That’s why and how we are  involved in the community development and contributing to OpenStack.


Besides code contribution mentioned above, what else have we done for OpenStack in the last 6 months?

As the early OpenStack dev team who operates the first production OpenStack cloud in China, we have done lots of work to promote OpenStack in China, as well as building COSUG to be the most active and influential open source user group in China. To be specific:

  • Among our 174 patches, some of which are tagged with high priority and critical for stability and usability of OpenStack projects, including:
  • Leading the COSUG to be the second largest user group after the official OpenStack community, with around 3000 members in total according to COSUG Updates presentation by Hui Cheng in Shenzhen OpenStack meet-up. We often plan and organize regular online and off-line OpenStack meet-up in Beijing and other cities, building a bridge connection for OpenStack developers, users and companies to communicate and share their insight regarding OpenStack and cloud computing.
  • As the lead manager of COSUG, our team leader Hui Cheng is responsible for operating the OpenStack Chinese portal,,  COSUG ML, COSUG official Weibo account @OpenStack(, and OpenStack events arrangement.
  • We devoted much time and energy in co-organizing the OpenStack Asia/Pacific Conference(OSAC) held in August, 2012, in Beijing, making it a successful and largest cloud event in Asia. It is the conference that make OpenStack and its community widely known and recognized  by most Chinese IT employees and companies.
  • We co-founded China Open-Source Cloud League(COSCL) with Intel,  which officially supports their developers to share R&D resources and jointly participates and contributes to Openstack official projects and the community.See news report about COSCL then.
  • We initiated projects, for is not accessible from China for same reasons.  StackLab is an fully accessible OpenStack Laboratory which now mainly provides an free OpenStack sandbox for the cloud developers, users and anyone else who is interested in OpenStack, testing and experiencing OpenStack.We have attracted more than 200 registered users in less than 1 week.  Here is StackLab news report and its HOWTO document.
  • We have planed the nationwide OpenStack promotion campaign, OpenStack China Tour, which is a series of meet-ups in Chinese major cities, covering most active OpenStack users and developers in China, such as Beijing, Shenzhen, Chengdu, Wuhan, Xi’an and Shanghai, and possibly more cities will be involved in.
  • We also have published articles and blogs about OpenStack projects and market opportunities  through InfoQ, CSDN, Programmer Magazine and our multi-language team blog, these articles, blogs and our slides have been being regarded as important sources and reference for Chinese OpenStack users to know and learn OpenStack.

What’s more?

At the last OpenStack Conference and Design Summit in April, we shared our work through presentation Integrating OpenStack To Existing Infrastructure, and  Dough: OpenStack Billing Project.

For the upcoming OpenStack Summit at San Diego, we have prepared one presentation DevOps in OpenStack Public Cloud, and one design proposal Local Storage Volume plugin for Cinder for Grizzly, looking forward to seeing you guys in the grand meeting.

In August, 2012, I was elected by the individual members of the OpenStack global community as a board member of OpenStack Foundation, that drives me to continue contributing, promoting, and more deeply involved in OpenStack projects and the community.


Even though we have done these work, I would consider this is not enough, we still have large space to do better and more.

For example, even though we have good scores if counted by changeset or bugfix, the average changed lines is not very high compared the developers from Rackspace, RedHat and others. The rank by code influence is not high as well, and so far we do not have a core developer in any projects, and so on.

But we believe Sina OpenStack dev team will definitely have much more progress and more contributions in Grizzly.

In the end, we must thanks the OpenStack community, and the newly founded OpenStack Foundation, who help us grow up,  give us guidance to how to communicate and how to delve into the core of OpenStack.(See OpenStack Foundation birthday global meet-up in Beijing)

More importantly, OpenStack gives us great opportunity to success, not only in career, but also in business.


This article is translated to Serbo-Croatian language by Anja Skrba from

Starter docs and articles

I wanted to send a note out to discuss the growth of all the starter docs and “articles” on a particular topic. Thanks all who are sending these as links to the mailing list or tweeting ‘em. We are listening.

The doc team has been discussing ways to ensure we help people find what they seek while still getting high-quality content into the “official” documentation. Here are some ideas. I’d like to get input from our wider community as well.

What we’re doing:

  • Add a “Where do I start?” section to the docs landing page. Let us know what you think of this approach by taking a look at the pending review. We discussed quite a bit a more friendly approach to the docs site but I haven’t identified a web dev and designer to do the re-do, contact me if you’re interested.
  • Reach out to writers and where licensing allows and something “official” is not already documented, bring the content into the official docs. We’ve done this a few times now, an example is how to custom brand the OpenStack Dashboard.
  • Add link to helpful blog entries to a “BloggersTips” wiki page.
  • Expand the install/deploy guide to include more distros so the “single distro” guides can standalone. This effort is still a work in progress.
  • Hastexo has offered to write a separate high availability (HA) guide, so we won’t bring in their 12.04 “all in one” install guide after all, since the CSS OSS Starter Guide covers a similar scenario.
  • Remove “articles” from RST docs. (Currently nova only, in further discussion with the Project Technical Leads, QA and CI team leads.)
  • Add blog URLs to the Google Custom Search Engine at I took this as an action item from our last doc team meeting.

What we’ve discussed:

  • Removing redundant docs. At the Design Summit, members of the nova core team asked for removal of “article” style RST documents from the nova source repo, creating a more doc-string based Members of the swift core team, when asked, did not want to go to this architecture. I haven’t specifically asked all the PTLs on this particular item. So there’s still a potential problem here of consistency, where to write what, and having all the sites that aren’t really tied together. I don’t have a good solution to suggest just yet but know we’re thinking about this particular problem. One idea was to have devs who want to write compose WordPress “articles” and that would aggregate together, but we haven’t found an ideal implementation (design is fine, working code, not so much).
  • Setting up a separate WordPress blog for documentation only. Apparently the aggregation tools just don’t give us all the requirements for version labels, bringing in one blog entry at a time (RSS feeds are needed), and so on.
  • Setting up a “support knowledge base” article site such as We discussed this at the last doc team meeting. It seems to solve a lot of problems we have, but my current thinking (which of course can change) is that a support KB is for troubleshooting articles, while the “official” docs should create a happy path. These are two different scenarios, and I’m pretty sure the docs team cannot take on the support scenario with our current resources. A support knowledge base with translation built-in will go a long way in supporting our growing base, so this is important to me, but not in the Folsom plans currently.

I’ll follow up with each PTL for the docstring discussion, and welcome all input. Thanks for reading this far, and thanks for the docs. Now get started!

Starting line

Back to top