The OpenStack Blog

Category: community

OpenStack Community Weekly Newsletter (July 11 – 18)

DefCore Update: Input Request for Havana Capabilities

As part of our community’s commitment to interoperability, the OpenStack Board of Directors has been working to make sure that “downstream” OpenStack-branded commercial products offer the same baseline functionality and include the same upstream, community-developed code. The work to define these required core capabilities and code has been led by the DefCore Committee co-chaired by Rob Hirschfeld (his DefCore blog) and Joshua McKenty (his post). You can read more about the committee history and rationale in Mark Collier’s blog post. The next deadlines are: OSCON on July 21, 11:30 am PDT and the Board Meeting on July 22nd.

And the K cycle will be named… Kilo !

The results of the poll are just in, and the winner proposal is “Kilo”. “k” is the unit symbol for “kilo”, a SI unit prefix (derived from the Greek word χίλιοι which means “thousand”). “Kilo” is often used as a shorthand for “kilogram”, and the kilogram is the last SI base unit to be tied to a reference artifact (stored near Paris in the Pavillon de Breteuil in Sèvres).

Five Days + Twelve Writers + One Book Sprint = One Excellent Book on OpenStack Architecture

A dozen OpenStack experts and writers from companies across the OpenStack ecosystem gathered at VMware’s Palo Alto campus for the OpenStack Architecture Design Guide book sprint. The intent was to deliver a completed book aimed architects and evaluators, on designing OpenStack clouds — in just five days.

Only developers should file specifications and blueprints

If you try to solve a problem with the wrong tool you’re likely going to have a frustrating experience. OpenStack developers use blueprints define the roadmap for the various projects, the specifications attached to a blueprint are used to discuss the implementation details before code is submitted for review. Operators and users in general don’t need to dive in the details of how OpenStack developers organize their work and definitely should never be asked to use tools designed for and by developers.

Third Party CI group formation and minutes

At this week’s meeting the Third-Party group continues to discuss documentation patches, including a new terminology proposal, as well as CI system naming, logging and test timing. There was also a summary review of the current state of Neutron driver CI rollout. Anyone deploying a third-party test system or interested in easing third-party involvement is welcome to attend the meetings. Minutes of ThirdParty meetings are carefully logged.

The Road To Paris 2014 – Deadlines and Resources

Security Advisories and Notices

Tips ‘n Tricks

Upcoming Events

Other News

Got Answers?

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

Welcome New Reviewers and Developers

Will Foster zhangtralon
Walter Heck Gael Chamoulaud
Mithil Arun Fabrizio Fresco
Kieran Forde badveli_vishnuus
JJ Asghar Ryan Lucio
Gilles Dubreuil Martin Falatic
Emily Hugenbruch Bryan Jones
Christian Hofstädtler Tri Hoang Vo
Steven Hillman Ryan Rossiter
Rajesh Tailor Mohit
akash Tushar Katarki
Rajini Ram Pawel Skowron
Pawel Skowron Karthik Natarajan
Abhishek L Ryan Brown
takehirokaneko Keith Basil
Kate Coyne
Ju Lim

Latest Activity In Projects

Do you want to see at a glance the bugs filed and solved this week? Latest patches submitted for review? Check out the individual project pages on OpenStack Activity Board – Insights.

OpenStack Reactions

youwelcome

Trivial fix on a review of someone else while he’s asleep so jenkins can pass

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

Five Days + Twelve Writers + One Book Sprint = One Excellent Book on OpenStack Architecture

Update: You can now download the OpenStack Architecture Design Guide here.

One thing about OpenStack is that you can find lots of information on how to do specific things, such as start an instance or install a test cloud on VirtualBox, but there isn’t much out there to give you the Big Picture, such as how to design a massively-scalable OpenStack cloud, or a cloud that’s optimized for delivering streaming content. That’s why this past week a dozen OpenStack experts and writers from companies across the OpenStack ecosystem gathered at VMware’s Palo Alto campus for the OpenStack Architecture Design Guide book sprint. The intent was to  deliver a completed book on designing OpenStack clouds — in just five days.

Now, I wrote my first book — a pretty straightforward introduction to Active Server Pages 3.0 — in seven weeks, and then it went through months of editing before arriving at the printer. I never wrote a more significant book that took less than six months.  So when I volunteered for the sprint, I confess that I didn’t expect much.  Oh, I knew that at the end of the week we’d have a book.  I just didn’t expect it to be the really great book that actually emerged.

How a book sprint works

Screen Shot 2014-07-14 at 4.45.58 PM

The process of actually writing the book was pretty regimented, but because we felt like we had control over the direction, we didn’t feel stifled by it.  We started by discussing the audience — architects designing OpenStack systems or evaluating it for use — and brainstorming a likely structure.

After deciding that we’d basically cover groupings of use cases for OpenStack clouds, we brainstormed all the different types we might cover, putting them on Post-its and grouping them on the whiteboard. (Let’s just say that “CI/CD” and “dev/test” were on a lot of our minds.)  Before long it was clear that we had seven major categories, such as “compute focused” or “massively scalable”.

We then broke into two groups, each of which was to take half an hour and brainstorm a structure for these categories.  Interestingly, although we used different terms, the structures the two groups emerged with were virtually identical.  (Which meant there was no fight to the death, which is always nice.)

From there our group of 12 broke into 3 groups of 4, each diving into a section.  At the end of Monday, we had 15,000 words already written (of which we’re still sure 10,000 came from Beth Cohen).

I was stunned.

I wasn’t stunned because we had so much content; I was stunned because it was, well, actually pretty good content.

By Wednesday morning, the book was pretty much written, and it was on to editing.  Groups read through sections written by others to try and fill in any holes, and Beth and I began editing, to try and even out the tone.  After that came two more passes: copyediting (by Alexandra Settle, Scott Lowe, and Sean Winn) and fact checking.

Long before Friday, we had a book that we could be proud of.

Screen Shot 2014-07-14 at 4.47.14 PM

What the OpenStack Architecture Design Guide covers

The OpenStack Architecture Design Guide is for architects and evaluators; deployment is covered in the OpenStack Operations Guide, so we didn’t cover that. The Design Guide covers the following types of OpenStack clouds:

  • General Purpose
  • Compute Focused
  • Storage Focused
  • Network Focused
  • Multi-site
  • Hybrid Cloud
  • Massively Scalable
  • Special cases (clouds that don’t fit into those categories, such as multi-hypervisor)

We talked about the different issues, such as user requirements, technical considerations, and operational considerations for each type of cloud, then talked about the actual architecture and provided some prescriptive examples to make things more concrete and easier to understand.

What community really means

Perhaps the most interesting thing about the book sprint is that it was, in many ways, a microcosm of OpenStack itself.  We all work for different companies, some of which don’t particularly get along, but in that room, it didn’t matter. We were just people getting a job done, and doing it in the best way we knew how, working long hours and joking about our evil overlords (sprint facilitators Adam Hyde and Faith Bosworth) and laughing about anything and everything to keep from going stir crazy.

We watched Alex learn that American Mountain Dew is very different from the stuff they have in Australia, and we saw her transform from a nervous newcomer to a confident writer and editor (though I’m still going to use two spaces after a period, sorry).  Anthony Viega and Sean Collins consistently impressed us with their knowledge of networking.  Sebastian Gutierrez showed how passionate he is about storage, and especially the wonders of Ceph. Vinny Valedez produced more great diagrams in two days than I did all of last year. Maish Saidel-Keesing and Kevin Jackson continuously inspired us to be better with their hard work and good humor. I’m still laughing at Steve Gordon’s deadpan humor.  (And I apologize to anyone who still has the music from Doctor Who stuck in their head.)

Our goal was to provide a resource for the OpenStack community, to help adoption of a tool we’re all passionate about. Did we joke about it?  Of course we did.  But at the end of the day, we wouldn’t have been there if we didn’t believe in the future of OpenStack, and what it can do, when it’s done right.

The OpenStack Architecture Design Guide will be available electronically free of charge as part of the OpenStack documentation, and like the Operations Guide and the Security Guide before it, it will be available for anyone to submit patches to, a living document that will only get better.  It will also be available for purchase in hard copy through Lulu.  Watch this space for a link!

DefCore Update: Input Request for Havana Capabilities

As part of our community’s commitment to interoperability, the OpenStack Board of Directors has been working to make sure that “downstream” OpenStack-branded commercial products offer the same baseline functionality and include the same upstream, community-developed code. The work to define these required core capabilities and code has been led by the DefCore Committee co-chaired by Rob Hirschfeld (his DefCore blog) and Joshua McKenty (his post).  You can read more about the committee history and rationale in Mark Collier’s blog post.

The DefCore Committee has introduced two key concepts that will be used to define the standard requirements across commercial products: Capabilities and Designated Sections. Capabilities represent the functionality that is exposed by an OpenStack-based cloud through APIs, which can be tested and reported on—for instance starting or stopping a virtual server. Designated sections are portions of upstream code from various OpenStack projects that are required in addition to the API-based capabilities. These requirements can change with each OpenStack release, and the DefCore committee has started with the Havana release to create an “advisory” set of requirements.  After community review on Havana, the Board will repeat the process for Icehouse requirements and then enforce those for the commercial trademark license programs.

Get Involved: Next week, the DefCore Committee will host two meetings for community input on the Capabilities they’ve scoped for the Havana release. The meetings will take place Wednesday, July 16, at 8 am PDT (1500 UTC) and 6 pm PDT (0100 UTC on July 17) to accommodate as many time zones as possible. You can reference the DefCore Committee’s current proposal, and join the meetings using the links on the following page:

After getting community input, the DefCore Committee plans to bring the proposed Havana Capabilities to the Board for approval at the next face-to-face meeting, taking place July 22nd in Portland, OR.  If approved, focus will then shift to the Designated Sections for Havana.

If you’d like to catch up on the work the Committee has been doing since the OpenStack Summit Atlanta, the following links contain the notes from their recent meetings:

https://etherpad.openstack.org/p/DefCoreLighthouse.1
https://etherpad.openstack.org/p/DefCoreLighthouse.2
https://etherpad.openstack.org/p/DefCoreLighthouse.F2F
https://etherpad.openstack.org/p/DefCoreLighthouse.3

 

OpenStack Community Weekly Newsletter (July 4 – 11)

OpenStack Swift 2.0 Released and Storage Policies Have Arrived

OpenStack Swift 2.0.0. This release includes storage policies – the culmination of a year of work from many members of the Swift contributor community. Storage policies are the biggest thing to happen in Swift since it was open-sourced four years ago. Storage policies allow you to tailor your storage infrastructure to exactly match your use case. This release marks a significant milestone in the life of the project that will lead to further adoption and community growth. You can get Swift 2.0 from http://tarballs.openstack.org/swift/swift-2.0.0.tar.gz. As always, you can upgrade to this version without any client downtime.

Wrapping up the Travel Support Program – Juno

The OpenStack Foundation brought 21 people to Atlanta for the Summit in May, thanks to the grants offered by the Travel Support Program, sponsored by VMware. The Travel Support Program is based on the promise of Open Design and its aim is to facilitate participation of key contributors to the OpenStack Design Summit. The Travel Support Application for the November Summit in Paris is NOW OPEN! You can apply for the Travel Support Program, including costs for travel and accommodation.

Missing Building Blocks for Enterprise OpenStack: Part 1 – High Availability

In the long term debate of pets vs cattle OpenStack has always been on the side of cattles. Dmitriy Novakovskiy shared his thoughts on why pets are good and how far away OpenStack is from supporting the more ‘legacy’ applications (TL;DR: not too far away).

Third Party CI group formation and minutes

At Juno Summit in Atlanta, Kurt Taylor, Anita Kuno, and Jay Pipes agreed to form a group focused on the Third Party experience, including but not limited to continuous integration. Part of the mission of the group is to focus on the quality of Third Party testing for OpenStack through improving documentation, gathering requirements, and easing the deployment of third party testing systems. The group has been working to improve the consumability of the components and documentation. They’re inviting all people involved in CI testing to join and help make the Third Party experience easier for developers and administrators to understand and deploy. The group holds regular weekly meetings. This week they discussed timelines for Cinder and Neutron testing, requirements for documentation patches, a proposal for system terminology and helped openATTIC solve its issues starting up the CI system.

Kudos Corner

It’s a great pleasure to highlight good examples of first time contributors to OpenStack getting through their first changeset proposal. Jeegn Chen‘s first changeset is one of such cases. Kudos to him and the community helping him fixing bug #1327497.

The Road To Paris 2014 – Deadlines and Resources

Reports from Previous Events

Security Advisories and Notices

Tips ‘n Tricks

Upcoming Events

Other News

Got Answers?

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

Welcome New Reviewers and Developers

Matthew Printz Slawomir Gonet
Fabio Massimo Di Nitto Prashanth Prahalad
azher ullah khan takehirokaneko
João Cravo azher ullah khan
Romain Soufflet Wayne
deven Vasiliy Artemev
Julia Kreger Dave Neary
Fabrizio Fresco Arnaldo Hernandez
Anant Patil Amit Kumar Das
Liyi Meng Shivakumar M
Richard Jones Richard Hagarty
Maurice Leeflang Michael Chase-Salerno
sh.huang
jizhilong
Rajesh Tailor
Chris Crownhart
Aleksandr Shaposhnikov
Matjaz Pancur
Alok Kumar Maurya
Jyoti
Andrey Epifanov
Abhishek L
Łukasz Oleś
Victor Chima
FeihuJiang
Mike King

Latest Activity In Projects

Do you want to see at a glance the bugs filed and solved this week? Latest patches submitted for review? Check out the individual project pages on OpenStack Activity Board – Insights.

OpenStack Reactions

wyfail

Elastic-recheck bot pointing us to which bug we need to recheck to

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.

OpenStack Swift 2.0 Released and Storage Policies Have Arrived

This blog post was first featured on the SwiftStack Blog, and you can find the original post here.

Today I’m happy to announce the release of OpenStack Swift 2.0.0. This release includes storage policies – the culmination of a year of work from many members of the Swift contributor community. Storage policies are the biggest thing to happen in Swift since it was open-sourced four years ago. Storage policies allow you to tailor your storage infrastructure to exactly match your use case. This release marks a significant milestone in the life of the project that will lead to further adoption and community growth.

You can get Swift 2.0 from http://tarballs.openstack.org/swift/swift-2.0.0.tar.gz. As always, you can upgrade to this version without any client downtime.

Storage Policies

What are storage policies, and why are they so important? Storage policies allow deployers to specifically configure their Swift cluster to support the different needs of data stored in the cluster.

Use case examples

Once the storage policies are configured, users can create a container with a particular policy, and all objects stored in that container will be stored according to that container’s storage policy.

Let’s explore two use cases enabled by storage policies: a reduced redundancy storage policy and a geographically-specific storage policy.

replication

We normally recommend 3x replication in Swift clusters. It provides a good balance between durability and overhead for most data. However, some data is trivially re-creatable and doesn’t require the same durability. A very good example of this is image thumbnails. If the original resolution image is stored with 3x replication, then a resampled image can be stored with 2x replication. This saves 33% on storage costs, and any data loss is mitigated by the ability to recreate the resized image from the original.

When used at scale to store and serve on-demand user-generated content, as Swift is used today, a “reduced redundancy” storage policy can save significant hard drive space, thus lowering costs. Storage policies can be created to enable different replication factors to be used in the same cluster, depending on the type of data that needs to be stored.

Another example is using different storage policies to geographically distinguish data sets. Suppose your company has a central office in Dallas, a branch office in New York, and a branch office in San Francisco. The data stored and used in one branch office doesn’t need to be shared with the other branch office, but the central office should have a copy of everything. With Swift 2.0, you can create a policy that references the storage capacity in Dallas and New York and another policy that references the storage capacity in San Francisco and Dallas. Now, anything stored in the “New York” policy will be stored in New York and locally available for fast lookup. It is the same with the “San Francisco” policy. But also the central Dallas office has a copy of everything that is being stored in the branch offices.

The central office can easily manage offsite archives and has very good visibility into each branch’s data consumption. Storage policies in Swift 2.0 augment Swift’s existing global cluster capabilities and allows finer-grained control over where the data resides.

Deployer Impact of Storage Policies

Conceptually, storage policies are pretty simple: where a Swift cluster used to support only one object ring, now it can take advantage of many object rings. Each ring in Swift describes a set of storage volumes (i.e. drives), and it includes information necessary for data placement and failure handling. With storage policies, deployers can configure their Swift cluster to support the different needs of data stored in the cluster.

It is safe for deployers to upgrade their existing clusters to use storage policies. And clusters can still be downgraded, at least until you define a second storage policy. If you have multiple policies configured and you revert to pre-storage policy code, any data in the new storage policies will be inaccessible, since older Swift versions do not know how to access it.

Storage policies are defined in the swift.conf configuration file. Existing clusters are treated as having a default “policy zero”. This means existing clusters can take advantage of the new code without needing to immediately begin supporting additional policies. New policies can be configured in that same config file and are then made available for clients. Each storage policy has a new ring.

safeupgrade

The developer docs for storage policies include quite a bit more information, including details about the on-disk data layout, deprecating policies, and changes to background consistency processes.

Client Impact of Storage Policies

Storage policies expand the Swift API in just one small way. When creating a container, a client can now send the X-Storage-Policy header to set the policy for that container. The value of the header is the name of the storage policy. And the name of the available storage policies is available from the result of a call to the cluster’s /info endpoint.

Existing Swift clients will still completely work with this new version of Swift. If a client sends a container create request and doesn’t also explicitly send the X-Storage-Policy value, the new container will be created with the cluster’s default policy. This means that existing Swift client applications will not stop working, and aside from setting a policy on a container, will be able to still take advantage of all Swift has to offer.

Storage polices can only be set on a container at the time of container creation. If you need to change a policy, you first must delete all data in the container, delete the container, then recreate the container with the new storage policy. However, since Swift places no limits on how many containers you can have, it’s normally easier to simply create a new container.

Community Participation

Storage policies in Swift would not be possible without the participation of the entire contributing community. In particular, Paul Luse (Intel), Clay Gerrard (SwiftStack), and Sam Merritt (SwiftStack) have been instrumental by providing tremendous focus, dedication, awesome ideas, and leadership to getting this feature designed, written, and merged.

Together with Paul Luse, I gave a talk on storage policies at the OpenStack Juno summit in Atlanta. You can watch it here.

Looking Forward to Erasure Codes

We began working on storage policies in Swift almost exactly one year ago. Last July, we wrote about adding erasure code support to Swift. Erasure codes are great because for some data sets they can offer tremendous savings in storage media while still providing very high durability. But to add erasure code support into Swift, we first needed to add storage policies.

Now that storage policies are available in Swift 2.0, the developer community is refocusing on building the necessary pieces to support an erasure code storage policy in Swift. Policies are the foundation upon which we are building erasure code support into Swift, and this will be a major focus of the Swift contributor community for the remainder of this year.

erasurecodes

Deploying Swift with SwiftStack

SwiftStack offers the easiest and fastest way to get up and running with a production Swift cluster. For more information on SwifStack, email contact@swiftstack.com, check out our online demo or signup for a personalized demo.

Wrapping up the Travel Support Program – Juno

The OpenStack Foundation brought 21 people to Atlanta for the Summit in May, thanks to the grants offered by the Travel Support Program, sponsored by VMware. The Travel Support Program is based on the promise of Open Design and its aim is to facilitate participation of key contributors to the OpenStack Design Summit. The program aims at covering costs for travel and accommodation for key contributors to the OpenStack project to join the community at the Summits.

We had 21 people accepted in the program from 8 countries and all around the world. Five people traveled from India, seven from Europe, three from Africa and the rest were from North America and South-East Asia. Of the selected recipients, two were unable to attend due to VISA timing issues, but we were excited to welcome the 21 attendees who were able to make the trip.

IMG_3139

The Foundation spent a total of $33,376 for flights and $7,751 for flights for a total cost for the Foundation of more than $40,000 USD including the costs of 10 access passes granted to non-ATCs (Active Technical Contributors).

The Travel Support Application for the November Summit in Paris is NOW OPEN! You can apply for the Travel Support Program, including costs for travel and accommodation.

The final deadline to submit applications is August 18th, so apply now!

OpenStack Community Weekly Newsletter (June 27 – July 4)

OpenStack Turns 4 – It’s Time to Celebrate the Community!

OpenStack celebrates its 4th birthday July 19, and we’re celebrating with the entire OpenStack community during July!  User maturity, software maturity and a focus on cloud software operations are rapidly emerging for OpenStack and none of it would be possible without the quickly growing OpenStack community. There are now more than 70 global user groups and 17,000 community members across 139 countries, spanning more than 370 organizations. This calls for a big toast to the OpenStack community members and our users.

OpenStack Technical Committee Update (July 1)

This week the TC held a special meeting entirely focused on clarifying some points around DefCore and providing some responses to the questions DefCore posed to the TC. A must-read.

We need to start uncovering OpenStack’s Hidden Influencers

After the summit (#afterstack), a few people compared notes and found a common theme in an under served but critical part of the OpenStack community. Sean Roberts, Allison Randall, and Rob Hirschfeld are expanding the discussion to the broader community in a series of blog posts.

Call for Speakers now OPEN – November Summit in Paris

The Call for Speakers is OPEN for the November OpenStack Summit in Paris! Submit your talks here: submit your talks now. Don’t wait! The Call for Speakers will close on July 28 at 11:59pm CDT.

Reports from Previous Events

Security Advisories and Notices

Tips ‘n Tricks

Upcoming Events

Other News

Got Answers?

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

Welcome New Reviewers and Developers

Jeegn Chen Richard Jones
Ciaran O Tuathail Mateusz Blaszkowski
Amit Prakash Pandey EliQiao
Melissa Wong warewang
Gael Chamoulaud Rakesh H S
François Magimel Maurice Leeflang
Tomáš Nováčik Markus Zoeller
Theron Voran Christopher Dearborn
Suthan Venkataramanaiah joanne
Jason Baker Tardis Xu
Harry Rybacki Rui Zang
Anthony Lee Ivo Vasev
Angela Smith Ian Cordasco
Anastasia Martynova stephen
Rikimaru Honjo
Alexander Maretskiy
Alex Weeks
Tim Hinrichs
Mike Bayer
Julia Kreger

Latest Activity In Projects

Do you want to see at a glance the bugs filed and solved this week? Latest patches submitted for review? Check out the individual project pages on OpenStack Activity Board – Insights.

OpenStack Reactions

nitpicking

Getting nitpicked on code reviews

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.

OpenStack – A Global Perspective: Five Things we Learned at OpenStack Events Across Europe and Israel

We say the words “global community” and “collaboration” so often they can start to lose their meaning. It’s easy to lose sight of the bigger picture, and the scale of our community far beyond name-brand users from the US or the number of Summit attendees. A few weeks ago, members of the OpenStack community organized a series of events across Europe and Israel, including Budapest, Paris, Milan, Tel-Aviv and London.I was fortunate enough to attend several events, and my goals were two-fold: to do some learning as we prepare for the November Summit in Paris, including getting a pulse on the issues and topics resonating most in the region and identifying new users we could feature; and second, of course, to start promoting the Paris Summit (shameless plug, happening November 3-7) by getting sponsors, press and potential attendees on board.

Jonathan

But what I really took away from the trip was a reminder that our greatest strength truly is the diversity and size of our global community. They aren’t just words that we throw around, but the hundreds of people we met and stories we heard in just a few short days. Reflecting on my conversations and a few interviews with the user group leaders, I wanted to pass along my five takeaways from the trip:

Businesses everywhere just want to move faster. Full disclosure, my original plan for this blog post was to interview the user group leader at each event and ask about the unique drivers in their region for OpenStack (or cloud and general). I suppose I shouldn’t have been surprised when they gave me essentially the same answers. The themes we discussed at the Atlanta Summit, including the Software-Defined Economy and needing to move faster than emerging competitors, resonated with everyone (unprompted!). Sure, there may be different regulatory environments or more financial services organizations in the UK and startups in Budapest, but at the end of the day they still want the same thing: the speed and agility to compete. The beauty of OpenStack is that there are many different ways to consume it, whether you’re a small business in Italy using Enter’s public cloud services, or building scale-out infrastructure for researchers to store and analyze data at CERN in Switzerland.

One of those user group leaders was Mariano Cunetti of Enter IT, based in Milan. According to Mariano, “the idea of team and company is changing. It has not been a painless process, but moving to the cloud is not only a matter of infrastructure. It’s not just a matter of how you develop your tools, it’s changing your processes. It’s being more agile and quick. In the next few years, the difference between companies adopting cloud compared to the ones who are not adopting cloud will be the difference of surviving and not.  Time to market will be so fast, that you need to keep the pace. You choose the pace you want to run to.”

London

Data sovereignty and national services create a different landscape in Europe, especially in industries like telco. I am familiar with the concept of data sovereignty and implications for our users, but one interesting thing we learned on the trip is that likely this year an update is coming to the EU-wide Data Protection Act Directive established in 1995. The new regulation, called the General Data Protection Regulation, is expected to take into account globalization and technological developments like cloud computing. As I mentioned, we’ve been talking about data sovereignty for some time — and it’s been a pretty significant driver of adoption among mid-size service providers across Europe and Australia — but debate and discussion around the new EU regulations, as well as court cases like Microsoft’s Dublin datacenter will be very timely for the OpenStack Summit in Paris, where we expect to discuss such issues with leading telcos, enterprises and technology vendors.

LivePerson

We’ve moved from “what” to “how.” Attending many of these same events a year ago, what really struck me is how the conversation has changed in tone. We’ve moved beyond the question of “what is OpenStack?” or “why OpenStack” to how it’s being used and more advanced topics. Attendees seemed eager for more technical deep dives and workshops. At the Paris event, Andrew Mitry from Comcast presented their user story, and had the most engagement and questions from audience members who were planning or operating their own deployments. In a short video interview, Nati Shalom, CTO of GigaSpaces and organizer of the OpenStack Israel Day, said: “When they were getting started, there was a lot of questions about whether OpenStack was the right thing. Is it going to happen? Is it going to be successful? Is it something that I should bet on? Even until last year that was the main discussion, but this year it’s more about how do I get started, how do I actually implement things, and how do I move fast with OpenStack.”

Budapest Check-in_2

Márton Kiss, who co-organized OpenStack CEE Day in Budapest, told me, “the major driving force behind this interest is that people started to trust the open source technology. The startups are definitive end-users of cloud technology, they know and use agile development, continuous integration / deployment, the entire devops culture, and OpenStack fits here as an alternative platform to Amazon. Larger enterprises here still have a conservative attitude, but telecom and financial sector are doing pilot projects. The structure of enterprises is a bit different in this Eastern European region, because most companies don’t have HQs here, but there are a lot of software development / technology center located here.”

Shuttleworth

Contribution pays off. One of the most exciting things to see is the companies who have been contributing — both code and community activities like organizing these events — have been making a name for themselves, and building their brand as OpenStack experts in the global community. They’ve gained knowledge and relationships that are translating into real business opportunities. We met some very large users who are choosing to work with smaller, focused companies in the OpenStack ecosystem because they know contributions equate to knowledge and influence. Companies who are consistently contributing are also openly attracting talent, because many of the OpenStack experts want to work in an environment where they know their efforts are going to have a broader impact. As one example, I was going to report on how impressive it has been to see eNovance grow and expand globally, because we had the chance to tour their new — OpenStack themed! — offices in Paris, but they’ve since been acquired!

Thierry

Need more focus on operations and end users. This isn’t so much a lesson learned on this trip, as it was reinforced by these events. The makeup of attendees has evolved from primarily vendors looking to productize OpenStack and contributing developers to infrastructure teams within larger enterprises and research organizations who are using the software. The content has also evolved, but there’s more we can do to focus on cloud operators and app developers. One thought is for the Foundation to help recruit and sponsor more users like Andrew Mitry to travel and speak at these events, because hearing case studies and having the chance to ask/answer questions first hand is incredibly valuable.Please feel free to weigh in, whether or not you attended the events, I’d love to get your perspective.

Thank you to all of the organizers who put significant time into these events: Márton Kiss and Gergely Szalay in Budapest; Annie Potvin and the eNovance (now Red Hat) team in Paris; Martina Casani, Mariano Cunietti and the Enter team in Milan; Avner Algom, Nati Shalom, Sharone Zitzman and the GigaSpaces team in Tel-Aviv; and Mark Baker, Cezzaine Zaher and the Canonical team in London.

I’m energized as we head to Paris in November, and hope to see you there.

OpenStack Community Weekly Newsletter (June 20 – 27)

OpenStack Technical Committee Update (June 25)

The TC is busy discussing OpenStack Glance‘s mission, evolving from cataloging and serving Nova disk images to cataloging and serving other artifacts consumed by other OpenStack services, like for example Heat templates. This scope evolution has been under discussion at the last two meetings. Read the other things that keep the TC busy on OpenStack blog.

A Path Towards Contributing (via Commits) in Open Stack

Matt Fischer set himself a goal to contribute 12 patches to OpenStack during 2014: he reached the goal and shared how he did it.

On bug reporting…

Speaking of contributing, sending bug reports is a good way to contribute to OpenStack (together with doing code reviews). Kashyap Chamarthy has a very good guide on how to file a useful bug report.

Engage in technical discussions keeping in mind the OpenStack promise

There is a conversation about what is Cinder itself and what’s the role of its drivers. It’s a highly technical debate and a very important one, where I think this promise needs to be reminded: There will be no “Enterprise Edition”. John Griffith and Ken Hui have a lot of interesting things to say about this and I suggest you to read their posts and read the conversation on this proposed specification. Then we may want to have a wider conversation about Software Defined Storage (SDS) and Cinder.

Reports from Previous Events

Security Advisories and Notices

Tips ‘n Tricks

Upcoming Events

Other News

Got Answers?

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

Welcome New Reviewers and Developers

Constanze Kratel Harry Rybacki
TaoBai David Pineau
Kevin McCarthy Angus Lees
Angus Lees Michael Turek
yalei wang IBM xCAT CI
Craig Bryant Clayton O’Neill
Ben Roble Tomáš Nováčik
pritesh Randy Bertram
Vishal kumar mahajan Kevin Fox
Tomoki Sekiyama Aaron Sahlin
Jyotsna yalei wang
sridhar basam
Tomoki Sekiyama
Matthew J Black
Anthony Lee
Jason Rouault
James Kremer
Craig Bryant

Latest Activity In Projects

Do you want to see at a glance the bugs filed and solved this week? Latest patches submitted for review? Check out the individual project pages on OpenStack Activity Board – Insights.

OpenStack Reactions

When your patch has passed half the tempest tests at the gate, and the other half is still running.

With sound

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.

OpenStack Technical Committee Update (June 25)

Two weeks ago, Russell Bryant inaugurated a series of blogposts about what the Technical Committee (“TC”) is working on. We will regularly post about the outcomes of the TC meetings, and rotate writers to give all TC members a chance to participate and describe what happens in their own words. This post will focus on what happened during the last two meetings.

The TC has several missions, and the topics we cover in TC meetings generally fall into one of them.

Mission #1: Integrated release contents

One of the missions of the TC is to determine what is part of the OpenStack “integrated release” that we collectively produce every 6 months. We manage the “incubation” process, through which selected projects can become part of the integrated release. We also keep an eye on already-integrated projects in case their scope evolves.

That’s the case currently for Glance, whose mission is evolving from cataloging and serving Nova disk images to cataloging and serving other artifacts consumed by other OpenStack services, like for example Heat templates. This scope evolution has been under discussion at the last two meetings. The principle of expanding Glance’s scope is pretty much accepted at this point, but the precise words to describe the new scope are still under discussion.

In order to set clear base expectations for projects in the incubation/integration process track, last cycle the TC came up with a reference document listing all the requirements for incubation, integration and the first integrated cycle that are consensual across TC members. This document is constantly revisited as we continue to raise the quality and convergence bar between integrated projects.

Last two meetings we have been discussing adding a translation support requirement for projects wishing to graduate from incubation. The main objection to it at this point is the lack of automated testing of the translated strings (which resulted in undetected I18N problems in the past). It looks like when this is addressed, this requirement will probably make it to the reference document.

Raising requirements for new entrants is one thing, but sometimes existing integrated projects do not fill those new requirements. This creates a gap that we need to address. During this cycle we reviewed most existing integrated projects (Heat and Swift are still pending). When a gap was raised, PTLs responded with a proposed “gap coverage plan” to address it.

The last project to go through that exercise was Glance, where a single gap around testing coverage was raised. Mark Washenberger (Glance PTL) created a gap coverage plan to address it and that plan was blessed by the TC at the last meeting.

Having plans is a good thing, but we also need to check that projects meet the deadlines that they set in such plans. Last week, after the juno-1 development milestone, we reviewed the progress on gap coverage plans. Ceilometer plan is on track, still targeting the juno-2 milestone for fully covering the gap. Horizon plan is mostly on track. Neutron has an ambitious gap coverage plan, and work on all gaps has started; gap 4 is a bit late (was planned to be completed by juno-1), but it’s also been determined to just be one API call. Trove plan is on track, and work started on all items.

Finally, having responsibility over the integrated release also means making sure we use terminology across integrated projects consistently. An issue was raised about the use of “certified” terminology to qualify CI testing on some projects. After open discussion on the -dev mailing-list and at the TC meeting, there was agreement that “certified” terminology was too loaded and should be phased out in favor of some variation around “tested”.

Mission #2: Representation of technical contributors

The TC is a directly-elected body representing all the technical contributors to the project. It is the final decision-making entity over technical matters in OpenStack as a whole. Some issues that can’t be solved at a lower level are sometimes escalated to the TC for final resolution, and the TC is also a convenient conduit for other OpenStack governance bodies to ask for general technical input.

Two issues were brought to the TC recently. The first one is about expected election behavior for our technical elections (PTLs and TC members). Our current election procedure doesn’t clearly describe expected behavior, and a proposal was raised to cover that. While everyone agrees on what is acceptable behavior and what is not, there are two ways of addressing issues if they arise. One is to piggy-back on the Community Code of Conduct, which clearly states that you should respect the election process. The other is to call out out-of-line behavior and trust the voters to make their own judgment about it. Both options are and will stay available, but we are still discussing which of those options (if any) we should encourage by making it part of the TC resolution. This discussion is on-going and will continue in a future meeting.

The other issue being brought to the TC were requests from the Foundation Board of Directors “Defcore” subcommittee for technical input to use as part of their work on trademark rules. There are two types of requested inputs. One is to provide for each project “designated sections” of code that you need to run in order to use the “OpenStack” trademark. The other is to give precise scoring for “core capabilities”: for each capability, indicate whether it’s part of the TC future direction or if it’s on its way to be deprecated.

While those inputs are technical (and we even voted on guidelines to help coming up with answers), some TC members expressed clearly their discomfort. Asking the representation of OpenStack contributors to designate parts of OpenStack that may just be replaced by proprietary alternatives (while still being called “OpenStack”) just crosses the line as to what they consider acceptable. Our “technical” answer might be read as an endorsement, or collaboration toward a behavior we don’t really want to encourage.

This tension has been surfacing every time Defcore was discussed at the TC meeting, and it’s difficult to address it between two topics in a one-hour online meeting. We have therefore scheduled a Defcore-specific TC meeting for July 1st (20:00 UTC in #openstack-meeting on Freenode IRC), and will try to clearly list concerns beforehand to ensure meeting clarity.

Back to top