OpenStack Community Weekly Newsletter (July 18 – 25)

How to Effectively Contribute to An Open Source Project Such As OpenStack Neutron

As Neutron’s Tech Lead (PTL), Kyle Mestery has been mostly heads down working to ensure the Neutron project has a successful Juno release. Increasingly, and especially near OpenStack Juno milestone deadlines, he’s forced to make hard choices and start turning new features down in order to focus on shipping good quality code for Juno. He sent an email to the openstack-dev mailing list this morning addressing the pressure his team is under. He also wrote a longer blog post to expand upon that email.

OpenStack Failures

Last week the bulk of the brain power of the OpenStack QA and Infra teams were all in one room, in real life. This was a great opportunity to spend a bunch of time diving deep into the current state of the Gate, figure out what’s going on, and how we might make things better. Sean Dague, Jim Blair, wElizabeth K. Joseph and bmwiedemann wrote a summary of the week.

OpenStack plays Tetris : Stacking and Spreading a full private cloud

CERN is running a large scale private cloud which is providing compute resources for physicists analysing the data from the Large Hadron Collider. With 100s of VMs created per day, the OpenStack scheduler has to perform a Tetris like job to assign the different flavors of VMs falling to the specific hypervisors.

Juno Updates – Security, Authentication and other neat things

There is a lot of development work going on in Juno in security related areas. Nathan Kinder wrote up some of the more notable efforts that are under way in Keystone, Barbican, Kite and other projects.

The Road To Paris 2014 – Deadlines and Resources

During the Paris Summit there will be a working session for the Women of OpenStack to frame up more defined goals and line out a blueprint for the group moving forward. We encourage all women in the community to complete this very short surveyto provide input for the group.

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

Mike Smith Roman Vasilets
Mika Ayenson Motohiro Otsuka
Claudiu Nesa David Yuan
Scott Reeve Amey Ghadigaonkar
Pawel Palucki Alexandr Naumchev
Travis McPeak Michele Paolino
Livnat Peer Marcus V R Nascimento
zhangtralon daya kamath
Ryan Brown arkady kanevsky
David Caudill Travis McPeak
FeihuJiang ChingWei Chang
Anusha JJ Asghar
Lee Yarwood Neetu Jain
François Magimel
Ashraf Vazeer

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

wnnng

My reaction when for the first time I had a contribution merged in OpenStack

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

Tags:

OpenStack Community Celebrates Four Years!

User maturity, software maturity and a focus on cloud software operations are now established areas of focus for OpenStack and none of it would be possible without the consistent  growth of the OpenStack community. In the four years since the community was established, OpenStack now has 70+ active user groups and thousands of active members spread across 139 different countries!Throughout the month of July, we are celebrating our community milestones and progress over the past four years, as well as Superusers who support the OpenStack mission. This year, we also launched the Superuser publication to chronicle the work of users, and their many accomplishments individually and organizationally amplifying their impact among the community.

2014_Singles_InfoGraphics_EP_12

We invite you all to join the party and celebrate 4 awesome years of OpenStack:

  • Check out the OpenStack 4th Birthday page featuring the latest stats, infographic and a web badge to download
  • Attend the birthday party in Portland, Oregon during OSCON, Tuesday, July 22
  • Attend your local birthday party, more than 50 are taking place around the world this month!
  • Visit the Superuser publication to learn about the contributors and user groups who make OpenStack successful
  • Join the conversation on Twitter today using the hashtag #OpenStack4Bday
Here are some community leaders’ perspectives reflecting on the past four years with OpenStack and their predictions for the future:

 

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

Tags:

Open Mic Spotlight, 4th Birthday Edition: Kashyap Chamarthy

kashyapThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun. For the month of July, we’re focusing on Q&A specific to OpenStack’s 4th birthday. If you’re interested in being featured, please choose five questions from this form and submit!

Kashyap currently works for Red Hat on most things related to open source virtualization/cloud related projects (OpenStack). He works remotely, from India. Kashyap enjoys reading, traveling, and learning to be conscious to live minimally and in an ecologically sustainable way.

1. Where were you when you first heard of OpenStack? What were you doing?

It was in 2012 in Brussels, Belgium. I was there to participate in the (no-nonsense) FOSDEM conference. For most of the second (and the last) day of the conference I was hanging out in the “Virtualization Dev” room and attended the final session of the day: an OpenStack community panel discussion moderated by Thierry Carrez (current OpenStack release manager) & co. Most of the debates in that session were around evolving project governance, roles of linux distributions, release process and plenty their related topics. That’s when I learned about OpenStack.

2. What drew you to OpenStack?

I got involved in OpenStack around 2013 through RDO project (a community OpenStack distribution that stays close to upstream trunk, started by Red Hat). I’d say it’s the sheer range of areas one can contribute to in many useful ways. By the time I was starting with OpenStack, it clearly helped to have been closely familiar with some of the under-the-hood open source virtualization technologies (like libvirt, QEMU, KVM and a ton of tooling around it) that OpenStack relies on. I feel it’s a nice progression to work on a higher-level project like OpenStack that already takes advantage of these and connects them all together in a meaningful way (and not some afterthought bolt-on).

Others factors would be OpenStack’s commitment towards technical meritocracy, its fair (walking the walk style) approach in governance and community interactions, and flat out fun in participating in such a large community-based software project.

3. What does “open source” mean to you?

To me, it’s the strong belief that it is the most sensible approach to develop software. Secondly, the realization that “hey, I get to benefit immensely from the work of scores of open source communities (at the tap of a keystroke — thanks to innovations like GPL, Creative Commons and the likes), so it’s just fair to contribute back to those communities on whose labour I’m building my existing work.”

4. Which OpenStack debate gets you the most fired up? Why?

Hmm, off the top of my head I can’t single out something. But there are a lot of interesting technical/community related debates on the very high-traffic upstream openstack-dev mailing list. It’s a great experience for a new person to learn the community culture by following discussions (with some good mail filters), getting a sense of tone on the lists, what kind of topics to bring up (and how) and many more things — just by plain old observation.

I don’t mean to imply that everything is rainbows and butterflies. Sure, there are (open/closed) conflicts too – like any massive project with a lot of moving parts, but the civilized manner in which most of them are resolved is heartening to see.

5. What is your favorite memory from am OpenStack summit?

I haven’t been to an OpenStack summit, yet. But I was at an OpenStack meetup (“OpenStack in Action 4″ by eNovance, last November in Paris). In the conference lobby, I noticed Mark McClain (current Neutron project PTL) passed by – I walked up, politely introduced my self and had a brief conversation. Before I left him alone, I asked him to share a piece of wisdom that can help one wrap his/her head around the complexity of Neutron (OpenStack Networking project) and its associated open source plugins. “Read ‘iproute2′ man pages, read carefully and experiment more, it’s full of useful details,” Mark said. And I still haven’t gotten to
it. So, by saying it out loud here, hopefully I’ll get my act together and spend some quality time with it. :-)

Tags:

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 [email protected], 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!

Tags:

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.

Tags: