The OpenStack Blog

Category: Uncategorized

Infrastructure Bootcamp

Recently the Project Infrastructure team hosted a two-day “bootcamp”
for people who are interested in contributing to the Project
Infrastructure.  The OpenStack project is so large, and continuing to
grow, that creating and operating the developer infrastructure for the
project itself is a unique challenge.  Because OpenStack receives code
contributions from more than 600 developers in a release cycle, and
merges as many as 200 changes per day, we are at the cutting edge of
distributed development and testing.

The project infrastructure covers a wide range of tools and services
used by the project, including code review, testing, and
collaboration.  The design and operation of these systems is managed
under the Infrastructure Program which is overseen by the TC just like
the rest of the OpenStack project.  And like any other OpenStack
program, our team is open and we welcome contributions from anyone.

Managing the infrastructure for a project of this scale is a lot of
work, but it is uniquely rewarding because it affects every OpenStack
project and affords interactions with all of the developers.  We heard
a lot of interest from persons and companies who wanted to contribute,
so we held the bootcamp to get anyone who was interested in
contributing together in a room with the current core team of
infrastructure developers.

OpenStack Infrastructure Bootcamp kicks off

OpenStack Infrastructure Bootcamp kicks off
Photo: Elizabeth Krumbach, CC-BY 2.0

Day one saw us all together and discussing how contributions are
accepted, how the team operates, and how new members can expect to
become core members in the future.  We discussed each major system at
a high level, and worked out how all of the systems interact with each
other.

In the evening, we all got together for dinner and spent several
enjoyable hours talking about how we could improve the system, and
generally getting to know each other.

On day two, we dove deeper into some topics of particular interest to
attendees, and generally had a less structured approach where people
who shared interest in an area got together and discussed it in depth.

I think everyone who attended got a lot out of the event, and we’re
already seeing significant new contributions as a result.  I hope that
in several months more time we will have new core members on our
team.  I also think this is a good model for other programs in
OpenStack who want to quickly bring new contributors up to speed.

I’d like to thank Monty Taylor for organizing the event, the rest of
the core contributors (or “coremudgeons”) for talking about what we do
for two days straight, and Hewlett-Packard and the OpenStack
Foundation for sponsoring the event.

Some reactions from others who attended:
http://dague.net/2013/06/29/openstack-infrastructure-bootcamp/
http://princessleia.com/journal/?p=8229

Open Mic Spotlight: Aaron Rosen

Aaron RosenThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful as we celebrate the third birthday of the project. Each day in July, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.  

Aaron Rosen currently works on OpenStack for Nicira/VMware. Most of his time is spent working on the Network Side (Neutron), though he also dabbles in the compute side (Nova). He’s most interested in networks, especially virtual ones. He graduated with a Masters in Computer Engineering from Clemson University in 2012, and joined Nicira right out of school. 

1. What’s the most critical feature you think cloud software needs to be widely adopted over the next year?

I would have to say Software Defined Networking (SDN). The network has been one of the major bottlenecks in the time that it takes to provision a new application. In addition, using traditional networking techniques such as VLANs are hard to manage and have scaling limitations. With SDN, it enables networks to be self service entities where users can provision networks, routers, load balancers, firewalls, etc. on demand via a self service portal, and deploy their application immediately. Previously, one would have to submit a help ticket and wait for the IT department to process it (some days or weeks later). In my opinion, this is one of the most important features of cloud and what the OpenStack Neutron (formerly Quantum) project aims to solve.

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

My most important contribution that I’ve made to OpenStack was the Security Group API implementation in Neutron. In Folsom, if one wanted to use security groups, one would need to use Nova’s security group implementation, which had a few limitations that we wanted to fix. The first limitation was that Nova security groups implementation did not work in conjunction with overlapping IP addresses. Since the point of Neutron was to let people have self-service control over their networking and addressing, this meant it was hard to use security groups with Neutron at all.  In addition, Nova’s security groups did not support egress filtering unless a tenant enforced this themselves within the instance.

Egress filtering allows tenants to enforce, which end hosts and protocols their instances are able to initiate communication with, which is useful if one wants to lock down who their instances can communicate with.

The last part of the security group work was to implement the ability for Nova to proxy its security group calls to Neutron. This is important because it allows one to create an instance via Nova and specific security groups in Neutron in addition to allowing existing scripts/tools to continue to work and allows Nova’s EC2 security group implementation to work with quantum.

3. Describe an interesting OpenStack deployment that you were part of, and why others ought to know about it. What made that project work? Tick?

At VMware we have an internal OpenStack cloud (~200 servers) that we use to host test/dev workloads and labs to demo our software to customers in addition to dogfooding our software on before it gets to customers. The interesting part of this deployment is that all of our developers use this as their primary development environment.

When I first joined the company, everyone was issued a server to run their VMs on that they were responsible for maintaining and running backups. Now, over a year+ since this cloud has been deployed, nearly every developer has returned their server that previously sat under their desk as it was no longer needed. I think what makes this deployment work is the dedicated and talented team that is tasked with maintaining this cloud and the open mindedness that its users have in the power that cloud provides. I’d have to say this is probably one of the most sophisticated cloud deployments out there powered by OpenStack with Nicira NVP for SDN, running both KVM and ESX hypervisors. I’m also proud to admit that we successfully upgraded this cloud from OpenStack Folsom to Grizzly a few months back!

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

  • Python! — Nuff said (Everything in OpenStack is written in Python.)
  • Open vSwitch — A programmable software virtual switch that most neutron plugins leverage to implement SDN.
  • Gerrit (http://review.openstack.org) – There are a few things I don’t like about it, but all in all I think it works well in order to keep track and review the massive amount of patches against OpenStack.

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

The compelling arguments that I would raise for deploying it would be that OpenStack is backed by a large community of users and companies. There are a large number of service providers deploying OpenStack, which allows you to cloud burst on demand to leverage public OpenStack clouds using the same automation you’ve already built around the OpenStack APIs.

Most importantly though, that it allows you to have flexibility to pick the best in class components from a variety of vendors rather then being forced into a vertically integrated stack.

OpenStack Summit Survey Results

As we gear up for the next OpenStack Summit in Hong Kong, and look forward to two more Summits in 2014, it’s a good time to take a look at the feedback from the April 2013 Summit in Portland.

We surveyed all Portland attendees, and almost 400 people responded. In this post I’ll break down some of the key findings and highlight a few changes we’re implementing in Hong Kong and beyond.

TL; DR Key Findings:

  • Overall: 96% of people rating the overall Summit as Good or Excellent. 
  • Top areas to improve:  Clearly the Network and the Session Rooms (size, acoustics, equipment) were unacceptable.
  • Format: Stackers favored keeping the Design Summit co-located with the rest of the Summit sessions by a margin of 4:1 over breaking it out separately

Ratings:

ChartExport

Regarding the “Session rooms” (size, acoustics, equipment), I attribute most of this to crowding issues, but there were also some technical glitches with the presentation equipment.

The Format Question:

ChartExport (1)

Among Active Technical Contributors (ATCs), who make up the majority of Design Summit attendees, the results were similar, but with more interest in making some change to the format. That said, keeping the overall event together was still preferred 2.5:1 over breaking it out completely:

ChartExport (2)

 

While the current format is the clear “winner” in the survey, there is always room for improvement.  Over the past 6 summits, we’ve had the most success when making incremental changes rather than completely overhauling the format.  Given the results of the survey, including the 96% rating of “Good or Excellent” I think this approach continues to make the most sense.

There were two free form questions, so I picked a few choice quotes:

“What did you find most valuable about the Summit?”

  • “The ability to get a large amount of information on OpenStack projects, progress, ideas, walkthroughs, and case studies, in a relatively short amount of time. Much better than web-based because it gets folks out of the office and thinking more constructively and creatively about OpenStack, and more passionate about it. This was my first summit, and attending it truly invigorated and greatly amplified my interest and enthusiasm in OpenStack in general.
  • “People, from all different backgrounds – both “world”-wise and Openstack-wise.”
  • “It was my first, so I was just racing from one talk to the next trying to soak up as much knowledge and personal connections as I could.”
  • “Workshops I attended & being able to speak with others who are right in the mix of OpenStack…”
  • “Hands-on labs and real world implementation strategies in the operations summit.”
  • “The fact that customers are now starting to show up at this summit is exciting.”
  • “To be able to finally meet people who I met on IRC and participate in design sessions. To be able to talk to customers.”

“What is the biggest area of improvement you see for the next Summit?”

  • “I think some logistics could improve; better wi-fi or even wired touchdown spots would be nice, since many of us need to keep working even as we’re enjoying the conference, and better sizing of the rooms to the presentations. Also the bag check idea I think would be excellent since the conference was not co-located with hotel. But overall a very well-run conference with lots of great content!”
  • “Removing barrier for non-native English speaker. They can do tremendous jobs in spite of their poor English.”
  • “Make sure participants can continue to ‘mingle’ while the number of attendees continues to grow…”
  • “1. Provide breakfast again :) 2. One evening event that accommodates all summit attendees 3. Better communication around the design sessions so they are not packed with non-ATCs.”
  • “- IRC nicks on badges – Better wifi, maybe have an on-site etherpad server since chunks of session time was lost to etherpad connection issues – Cold drinks available on site all day – don’t mind paying but never have time to go far – Conference being away from the hotel meant jetlag hurt more since going for a short nap was difficult”
  • “More seating!”

Planned actions for Hong Kong:

  • Network: We participated in a debrief with the networking company and are planning to evaluate additional vendors for Hong Kong, as well as engage with other organizations who have hosted conferences at Asia World Expo to learn more about their experience and any unique requirements we should be prepared for.
  • ATC Designation: We’re planning to make the ATC designation more clear and recognizable on the badges and include IRC nicknames. We’re also communicating that ATCs should register for the Summit with the email tied to their Gerrit ID in order to receive ATC designation on the badge.
  • Capacity & Crowding: In Hong Kong we are limiting “Full Access” passes – people who can attend the breakout sessions and Design Summit all four days — to a reasonable capacity based on room sizes, and offering a “General Session & Expo” pass with one track running Tuesday & Wednesday to better manage our growing base of attendees. Also, the “curtained off” area for the Design Summit received positive feedback in Portland and is a model we’ll pursue again for Hong Kong.
  • Design Summit Productivity & Scheduling: It has been proposed to move the PTL “project update” sessions to a series of webinars post-Summit, so they won’t conflict with Design Summit sessions, PTLs will have a chance to gather thoughts/feedback from the Summit and more people will have the opportunity to participate and ask questions online. ATCs were fairly split on having an additional moderator participate in the Design Summit sessions to help manage the room, slightly favoring bringing on the moderator.  Both of the topics are still under discussion. Regardless, we can take steps to more clearly identify “Design Summit” sessions within the online schedule and help educate Design Summit session leaders and attendees with best practices for a productive session.
  • Food & Drinks:  We will not be able to provide breakfast at the event in Hong Kong, but many of the hotel room blocks and budget-friendly recommendations offer free breakfasts. We are requesting healthier snacks for the developer’s lounge, per feedback from several developers, and we’re also planning to offer larger, reusable water bottles instead of the small plastic cups.

For 2014 Summits, we would like to continue evaluating the format, and considering the possibility of starting the Design Summit a day early (or ending a day later) relative to the other content, to reduce the scheduling conflicts for ATCs.   The data doesn’t scream out for this change, but I don’t want to dismiss it yet either for 2014.

Please keep the feedback coming! And start making plans for Hong Kong now!

@sparkycollier

 

Havana: An Enterprise IT Perspective

Intel IT has been working with OpenStack in our labs starting with Cactus, our first deployments into production were with Diablo, which we quickly moved forward to Essex and have been running production apps on this since the summer of 2012.  Since then we have been getting deeper and deeper into OpenStack, and recently had 8 of our Intel IT engineers approved to start contributing to the codebase, and have done our first contributions in the last few months.  May sound simple, but complex for a large enterprise shop like ours – and we are super jazzed to start contributing more and more…  looking forward to working as part of the community with more breadth and depth now thanks for having us :)

While we are in the midst of our Grizzly rollout, we are getting involved in the Havana specifics, and I wanted to share some of the key features we are excited about and share some of the use cases these help us with.

Our overall goal is to turn all of our data center into a software exposed environment, virtual machines, physical machines, networking, storage, and all of the components that make our complex and simple apps work at scale.  A number of the Havana features are really going to help make some big steps for us all into this level of capabilities:

At the foundation level, since we run traditional enterprise workloads along with new cloud-aware apps it is very important that resilient infrastructure solutions continue to improve, for instance live migration and restart on failure capabilities which are both supported by boot from volume block storage, and improvements in the orchestration code.  We also intend to use OpenStack to control physical nodes, therefore metal as a service work is increasingly important to us; our intent is to control our VMM sand physical nodes with one scheduler and one set of APIs/CLIs.

A lot of our work is happening at the higher levels of OpenStack, as we enable more complex applications and cloud-aware apps we need strong orchestration and automation for all of the resources OpenStack controls..  for instance we need auto-scaling, ability to deploy many machines in complex collections, controlling various networking asoects from IPs to firewalls all as part of the rollout of a single application.  Advances in HEAT to get us to a production level for our more advanced use cases are vital, as well as the improvements happening with LBaaS and OpenStack Networks.  We are also excited about the introduction of the service chaining concept which will let us declare our application flow and have OpenStack implement it from Internet all the way to the backend DBs.

As a large IT shop we also have to run our capacity like a supply chain so we need quotas and showback of resources for all of the services we expose to ensure the right usage behaviors while still allowing for rapid elasticity. Ceilometer across all resource types with granularity for users and projects get us to where we need for managing our capacity real time and with proper buffer capacity before new physical hardware lands, in turn allowing us to appear infinite in resources to our end users.

Speaking for the entire Intel IT Open Cloud team… the fast pace of the OpenStack community is why we decided to run this solution and contribute to it, we look forward to even more after Havana which will take our open cloud platform further out onto the cutting edge.  Don’t take a rest yet, we have a marathon we are on…. Hope to see you in November.

OpenStack Project Infrastructure Sees Rapid Growth

The OpenStack project infrastructure has grown tremendously over the
past year, and now is a great time to get involved in helping to run
one of the largest and fastest-growing open source projects!

The project infrastructure encompasses all of the systems that are
used in the day to day operation of the OpenStack project as a whole.
This includes development, testing, and collaboration tools.  All of
the software that we run is open source, and its configuration is
public.  In fact, the whole of the project infrastructure is run in
exactly the same manner as the rest of the OpenStack project: anyone
may contribute a configuration change via code review, and then a team
of core reviewers provides feedback and may eventually approve the
change for merging.

As the OpenStack project has grown, so have the services provided by
the infrastructure team.  The code review system, Gerrit, now houses
134 source code repositories.  The scope of the project infrastructure
is so broad that it comprises 24 of those repositories, including
software in languages such as Java, Python, shell, Ruby, and Puppet.
We work on exciting projects that include how to test and facilitate
distributed development at a large, and rapidly growing, scale.

New contributors to the OpenStack project infrastructure are welcome.
We recently began reorganizing our documentation to focus on helping
people make their first contribution.  You can read about our systems
and how we operate at <URL: http://ci.openstack.org/>.

Contributions to the project infrastructure are highly valued by the
project as a whole.  If you’re interested in helping the OpenStack
project grow, and working with a wide variety of systems that impact
every developer working on OpenStack sounds fun, we’d love your help.
If you are willing to make a significant time commitment to the
project infrastructure, we are scheduling a new-contributor bootcamp
in New York, NY on June 27 and 28.  If you’re interested in attending,
please contact Monty Taylor <mordred@inaugust.com>.

Ripple Effect

I enjoying hiking, and one trek I enjoy is a climb to over 10,000 feet within the Great Basin National Park to a small lake called Stella Lake.  Stella is very small and insignificant, if measured by size and depth. It sits at the foot of a small ancient glacier cirque sheltered by 13,000-foot Wheeler Peak.

Stella is cold and clear, fed by pure forested winter snows. Its remote location preserves its pristine environment. Its sheltered location creates an atmosphere of calm serenity. On many of my visits, the air has been so calm the surface of Stella was as a mirror, reflecting the beauty of the granite cliffs, evergreen trees, clean blue skies, and cottony white clouds off its clear glassy surface. The toss of a small stone into such still waters ripples across the entire lake reaching the farthest shores, catching the silver sparkles of the sun in its wake.

The ripple effect.  Where a seemingly localized action transfers to great distances.

With all that is being accomplished within the OpenStack project, we should not forget about the ripple effect.  This effect occurs daily through the associated commercial and community open source projects tied into the project. An OpenStack release, such as Grizzly, is like a toss of a stone into the waters of the cloud ecosystem.

Many community projects and commercial ventures closely follow the OpenStack project through the life of each release.  Tracking changes on a daily basis they see the code, learn from it, adapt it, and enhance it.  Processes that not only ripple out to the Cloud ecosystem but ripple back into the OpenStack project as well creating a mutually beneficial relationship.

Community open source projects check out the changes, build OpenStack within their own projects, run functional and unit tests for each component, and put the code through its paces.  Their  development processes included additional code reviews, component integration and testing tailored to their community or organization projects.  Through their processes additional bugs are quickly found and fixed.  Through their efforts OpenStack is distributed as a part of their projects. Through their efforts OpenStack receives the ripple effect of return contributions through reported bugs, patches, and feature enhancements.

Commercial programs conduct similar testing and review steps while typically adding service and support for a variety of platforms, middleware, and applications. Their contributions back to the OpenStack project provide increased quality and more easily integrated software.  Attributes that keep getting better with each OpenStack release.

As you can see the ripple effect not only extends OpenStack into a worldwide distribution but into a worldwide community.  A community of vastly growing knowledge and ideas.  Quite simply, the ripple effect helps make open source software better, faster.

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 www.ericsson.com and www.juniper.net

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!

Enter OpenStack’s T-shirt Design Contest!

SmallTshirtDesignContestAd

Show us your creative talent & submit an original design for our
2013 OpenStack T-shirt Design Contest!

  • Winning design will be announced the last week in August 2013
  • Original artwork will be showcased on T-shirts given out at LinuxCon Cloud Open in New Orleans, September 16-18, 2013 as well as future events worldwide
  • Creator of the winning design will receive attribution on the T-shirt and public recognition on OpenStack’s website
  • Submissions will be accepted through August 1, 2013
  • Email submissions to claire@openstack.org -  Subject: OpenStack T-Shirt Contest

For reference, view current OpenStack T-shirt designs HERE.

Submitting an entry:

  • Please make file Actual Size in inches (up to 10″ x 10″)
  • Digital art entries only; high-resolution (300 dpi) layered .psd/.eps/.tif (Photoshop) file or .ai/.eps Vector Files (Illustrator) are preferred
  • Do NOT send Microsoft Office files or Low- Resolution Files
  • There should be no embedded bitmap images (jpg, tif, bmp)
  • Colors should be spot with no half-tones
  • Convert and group all fonts to outlines
  • Please notate the preferred T-shirt color for printing
  • Please provide a jpg/png/screenshot of the completed artwork to act as a proof for your submission files.
  • Email submissions to claire@openstack.org Subject: OpenStack T-Shirt Contest
  • Submissions will be accepted through August 1, 2013
  • Note: If you have any questions about how to properly submit your file, please contact email questions to claire@openstack.org Subject: T-Shirt Contest Help

Guidelines:

  • The design must be your own original, unpublished work and must not include any third-party logos or copyrighted material; by entering the competition, you agree that your submission is your own work
  • Design should be one that appeals to the majority of the OpenStack developer community
  • Deign may include line art, text, and photographs
  • Your design is for the front of the shirt and may encompass an area up to 10″ x 10″ (inches)
  • Design may use a maximum of three colors

The Fine Print

  • Maximum of one entry per person.
  • Must be original art. Content found on the internet rarely has the resolution needed for print and is often considered unlawful to use without permission
  • Submissions will be screened by the OpenStack Foundation for merit and feasibility
  • The OpenStack Foundation marketing staff will select the contest winner
  • The OpenStack Foundation reserves the right to make changes to the winning design before printing, including changes in image size or ink color or t-shirt color.
  • By submitting your design, you grant permission for your design to be used by the OpenStack Foundation including, but not limited to, the OpenStack website, the 2013 OpenStack Cloud Open T-shirt, and future marketing materials
  • The OpenStack Foundation reserves the right to final decision
  • The creator of the winning design will receive attribution on the T-shirt and public recognition on the OpenStack website

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
security
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.

Interoperability
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.

Transparency
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.

Elections
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.

Conclusion
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.

Regards,

OpenStack Board of Directors

Germany, Israel & Hungary – OpenStack Events

Jonathan Bryce and a few members of the OpenStack Foundation team will be heading to Europe later this month to attend three key regional events. Jonathan and other noteworthy members of the OpenStack community will be speaking at each event. If you are in the area and would like to learn more about OpenStack or network with others in the community – please plan to attend!

Help us spread the word, and we hope to see you there!

Berlin, Germany – Friday, May 24

Screen Shot 2013-05-02 at 11.20.29 AM

OpenStack DACH Day 2013 will provide attendees with first­hand insights from OpenStack developers and enterprises that are successfully using OpenStack in production environments for both private and public clouds. The lineup includes speakers from industry leaders including:

  • Jonathan Bryce, OpenStack Foundation
  • Kurt Garloff, Deutsche Telekom AG
  • Monty Taylor, HP
  • Bernhard Wiedemann & Sascha Peilicke, SUSE
  • Muharem Hrnjadovic, Rackspace Cloud
  • Dr. Wolfgang Schulze, Inktank
  • Tobias Riedel, Netways
  • Dr. Udo Seidel, Amadeus Data Processing

Register to Attend:

  • When: Friday, May 24, 2013
  • Where: Berlin Fairgrounds (Messegelände unter dem Funkturm), Hall 7, as part of LinuxTag
  • Tickets: Registration is free, and there 200 tickets available at http://openstackdach2013.eventbrite.com

Tel Aviv, Israel – Monday, May 27

Screen Shot 2013-05-02 at 10.51.04 AM

Join the OpenStack community for the third OpenStack Israel event, co-organized by OpenStack community supporters IGTCloud and GigaSpaces. The event is sponsored by the OpenStack Foundation and includes speakers from across the OpenStack community. Hear about OpenStack’s newest Grizzly release from the source, deep-dive into the Quantum network, learn about the new Cinder storage, hear what others are doing with OpenStack technology with real-life case studies from Intel, Liveperson and Alcatel, and meet the top industry leaders from IBM, HP, Rackspace, RedHat, GigaSpaces, DreamHost, Radware, Ravello, Mirantis, Cloudsoft and Hastexo.

Register to Attend:

  • When: Monday, May 27, 2013
  • Where: Herzilya Arts Center at 15 Jabotinsky Street in Herzilya, Israel
  • Tickets: Registration is free, but there are only 300 tickets available, so register quickly! http://www.openstack-israel.org

Budapest, Hungary – Wednesday, May 29

Screen Shot 2013-05-02 at 10.50.39 AM

Join us for OpenStack CEE Day – a large-scale one day user conference for the Central & Eastern European region. Attendees will get insights to OpenStack from industry-leading keynote speakers, as well as user case studies, workshops and deep dive sessions. The OpenStack CEE Day welcomes users, prospective users, ecosystem members, partners, developers and everyone who is excited about OpenStack’s open source cloud innovation.

Register to Attend:

####

Check out the latest hastexo blog post about each of these events – It’s May. It must be OpenStack Month! 

Follow @OpenStack on Twitter for the latest news.

Back to top