Writing Your First OpenStack Application

Ever thought about what it takes to write a scalable cloud application using an OpenStack SDK? Thanks to a small team’s heroic effort, there’s now a guide for that!

Christian Berendt (B1 Systems), Sean Collins (Mirantis), James Dempsey (Catalyst IT) and Tom Fifield gathered in Taipei, with Nick Chase live via video link, to produce “Writing Your First OpenStack Application” in just five days. The sprint was organised by the Application Ecosystem Working Group, with the financial support of the OpenStack Foundation.

The new work is aimed at software developers who want to build applications on OpenStack clouds and also shares some best practices for cloud application development.

Inspired by Django’s first app tutorial, where a simple polling app is used to explore the basics of working with Django, “Writing Your First OpenStack Application” uses an app that generates beautiful fractal images as a teaching tool to run through areas like:

  • Creating and destroying compute resources.
  • Scaling available resources up and down.
  • Using Object and Block storage for file and database persistence.
  • Customizing networking for better performance and segregation.
  • Making cloud-related architecture decisions such as turning functions into micro-services and modularizing them.

The guide has been written with a strong preference for the most common API calls, so it will work across a broad spectrum of OpenStack versions. In addition, the authors have paid special attention that the first few sections should work almost regardless of OpenStack cloud configuration.

A core part of the guide’s design is support for multiple SDKs. The initial version was written and tested with the libcloud SDK, but work is underway for python-openstacksdk, pkgcloud and fog which will re-use the text with new code samples.

So, check out “Writing your First OpenStack Application” for libcloud, watch the introductory presentation from the summit, or consider helping complete the samples for other languages.




Taipei 101 (c) James Dempsey

Taipei 101 (c) James Dempsey

Each post-it note represents an area that had to be written.

Each post-it note represents an area that had to be written.

Enjoying local Taiwanese food after a hard day's writing.

Enjoying local Taiwanese food after a hard day’s writing.

5 years of OpenStack – it’s time to celebrate the community!

OpenStack celebrates its 5th birthday July 19, and we’re celebrating with the entire OpenStack community during July! Cloud interoperability and support for developer productivity have been focuses for the OpenStack project this year, and none of it would be possible without the quickly growing OpenStack community.

There are now more than 80 global user groups and 27,300 community members, across 165 countries, spanning more than 500 organizations. Over 30 million lines of code have been written in less than five years thanks to our thriving community of developers and users around the world. This calls for a big toast to the OpenStack community members and our users.




We’ve invited all our user groups to celebrate with us. During the month of July, more than 35 OpenStack birthday parties will be thrown all over the world – celebrating the OpenStack community!  We encourage everyone to find a birthday party in your area and join your fellow community members to toast each other on another great year! If you don’t see a celebration in your area, not to worry – several more parties are to be announced soon. Don’t forget to share your pictures and memories using #OpenStack5Bday.

If you’re attending OSCON, the Foundation invites you to come celebrate the OpenStack Community on Tuesday, July 22nd at the LeftBank Annex to mingle with other community members and Foundation staff. Stay tuned – more details coming soon!

Find a local celebration in your area:

Argentina July 15

Atlanta July 18

Austin July 28

Baden-Württemberg July 15

Bangalore, India July 11

Brazil July 25

Bucharest, Romania June 30

China – ShenZhen July 11

Colorado (Denver Metro/South) July 16

Fort Collins, Colorado July 16

Greece July 1

Hong Kong July 14

Hungary July 16

Israel July 13

Italy July 14

Japan July 13

Kenya, Africa July 11

London July 21

Los Angeles July 16

Melbourne, Australia

Moscow, Russia, July 22 

Mumbai, India July 25

New Delhi, India July 11

New York July 15

North Carolina July 23

North Virginia July 7

Paris, France June 30

Philadelphia July 16

Philippines June 29

San Francisco Bay Area July 9

Seattle, July 16 

Sevilla, Spain July 1

Slovenia June 23

South Korea August 5

Stockholm/Nordic July 21

Switzerland July 17

Sydney, Australia July 15

Thailand July 17 & July 18

Tunisia July 22

Turkey July 22

Vancouver, Canada July 16

Vietnam July 4

Virginia July 9

Washington DC Metro Area July 20

OpenStack Community Weekly Newsletter (June 19 – 26)

New OpenStack component versioning

Thierry Carrez explains why the Liberty-1 milestone release has some unfamiliar version numbers for familiar projects.

Technical Committee Highlights June 25, 2015

A compute starter kit tag has been approved, it provides a place for a beginner who only wants to try to get a computing cloud use case started. New projects under the OpenStack “Big Tent”: Searchlight, OS-ansible-deployment (OSAD), Solum and Cue Message Broker service.

Forrester says: ready, set, OpenStack!

A recent report from Forrester gives a major boost to OpenStack adoption, calling its “viability and presence in the market irrefutable.” You can download the entire report for a limited time on the OpenStack.org website.

The Road to Tokyo

Reports from Previous Events

  • None this week

Relevant Conversations

Deadlines and Contributors Notifications

Security Advisories and Notices

Tips ‘n Tricks

Open Call for Proposals

Recently Merged Specs

Subject Owner Project
Clean up tenant resources when one is deleted Assaf Muller openstack/neutron-specs
Fixes for generic RAID interface Devananda van der Veen openstack/ironic-specs
Add spec for reference implementation split Kyle Mestery openstack/neutron-specs
Add Spec Lifecycle Rules to readme Matthew Oliver openstack/swift-specs
Add uuid field to security-groups for server show heijlong openstack/nova-specs
Add spec to enhance PCI passthrough whitelist to support regex Moshe Levi openstack/nova-specs
Moved driver interface from backlog to liberty Ajaya Agrawal openstack/keystone-specs
Update monasca spec with version 5.0.0 Kanagaraj Manickam openstack/heat-specs
Add Zone Exists Event Spec Kiall Mac Innes openstack/designate-specs
VLAN aware VMs Erik Moe openstack/neutron-specs
Allow unaddressed port(without l3 address, subnet) and to boot VM with it Isaku Yamahata openstack/neutron-specs
Uniform Resource Signals Miguel Grinberg openstack/heat-specs
Decompose vendor plugins/drivers for neutron-*aas Doug Wiegley openstack/neutron-specs
Lbaas, use Octavia as reference implementation Doug Wiegley openstack/neutron-specs
MySQL manager refactor Alex Tomic openstack/trove-specs
Add virt-driver CPU thread pinning Stephen Finucane openstack/nova-specs
Implement external physical bridge mapping in linuxbridge Li Ma openstack/neutron-specs
Add port timestamp Zhiyuan Cai openstack/neutron-specs
Add availability_zone support IWAMOTO Toshihiro openstack/neutron-specs
PowerVM Compute Inspector Drew Thorstensen openstack/ceilometer-specs
Add rootwrap-daemon-mode blueprint Yuriy Taraday openstack/nova-specs
Add heat template-version-list command to cmd Oleksii Chuprykov openstack/heat-specs
Add a str_split intrinsic function Steven Hardy openstack/heat-specs
Add spec for more-gettext-support Peng Wu openstack/oslo-specs
trivial: Change file permissions for spec Stephen Finucane openstack/nova-specs
Action listing Tim Hinrichs openstack/congress-specs
libvirt: virtio-net multiqueue Vladik Romanovsky openstack/nova-specs
Spec for adding audit capability using CADF specification. Arun Kant openstack/barbican-specs
libvirt: set admin root password sahid openstack/nova-specs
Report host memory bandwidth as a metric in Nova Sudipta Biswas openstack/nova-specs
Adds Hyper-V Cluster spec Claudiu Belu openstack/nova-specs
Inject NMI to an instance Shiina, Hironori openstack/nova-specs
Add a Distinct Exception for Exceeding Max Retries Ed Leafe openstack/nova-specs
Fix error messages on check-flavor-type Ken’ichi Ohmichi openstack/nova-specs
Add BuildRequest object Andrew Laski openstack/nova-specs
Groups are not included in federated scoped tokens Dolph Mathews openstack/keystone-specs
Add spec for event alarm evaluator Ryota MIBU openstack/ceilometer-specs
nova.network.linux_net refactor Roman Bogorodskiy openstack/nova-specs
user_data modification Alexandre Levine openstack/nova-specs
Add support for Redis replication Peter Stachowski openstack/trove-specs
Adds spec for modeling resources using objects Jay Pipes openstack/nova-specs
Add tooz service group driver Joshua Harlow openstack/nova-specs
Add List of Group-IDs to ACL for Secrets/Containers John Wood openstack/barbican-specs
Specification for spark-jobs-for-cdh-5-3-0 added Alexander openstack/sahara-specs
Scheduler Introduce lightwieght transactional model for HostState Nikola Dipanov openstack/nova-specs
DNS resolution inside of Neutron using Nova instance name Carl Baldwin openstack/neutron-specs
Allow multiple clusters creation simultaneously Telles Mota Vidal Nóbrega openstack/sahara-specs
Update the backlog spec page John Garbutt openstack/nova-specs
Add spec for decoupling auth from API versions to backlog Morgan Fainberg openstack/keystone-specs
Let users restrict stack-update scope Ryan Brown openstack/heat-specs
Update of `support-modify-volume-image-metadata.rst` Dave Chen openstack/cinder-specs
Add ability to abandon environments Dmytro Dovbii openstack/murano-specs
Add the oslo_db enginefacade proposal Matthew Booth openstack/nova-specs
Track cinder capacity notifications XinXiaohui openstack/ceilometer-specs

Upcoming Events

Other News

OpenStack Reactions

Rushing to see if my bug was fixed in the release note

Rushing to see if my bug was fixed in the release note

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.

Technical Committee Highlights June 25, 2015

Beginners, start your engines

A compute starter kit tag has been approved, it provides a place for a beginner who only wants to try to get a computing cloud use case started. We discussed some reservations about recommending such a simple starting point, including only using nova-network for inter-vm networks, and recommending multi-host for that use case, but feel the current tagged projects indicate a decent starting point for now. We’ll update it as we see improvements to the starting experience. The projects for an OpenStack starter kit are: cinder, glance, keystone, and nova. Additional tags are being proposed to help with the release mechanisms for a type:service tag, and type:library tag merged this week.

Welcome, new projects

We welcomed new projects to the “we are OpenStack” definition, including:

  • Searchlight, providing indexes and search across cloud resources
  • OS-ansible-deployment (OSAD), deploying OpenStack using Ansible playbooks
  • Solum, managing the application lifecycle and source-to-image workflows
  • Cue Message Broker service project proposal, for deploying and managing message brokers using a REST API

There were several topics we didn’t get to discuss in this meeting due to the longer discussion about the compute starter kit, but we will get to those next week. Check the meeting agenda on the wiki any time you wonder what topics are up for discussion.

Project Team Guide sprint

The sprint for the Project Team Guide was last week, and the authors are going great gangbusters. The goal for this guide is to provide teams a starting point for understanding our philosophy and general thinking about what it means to be an OpenStack project. See the review queue for the work in progress. It’s not published to the web yet, so if you’d like to write or revise anything, propose a patch for review to the project-team-guide repository and build it locally.

Awaiting the M name

The poll for the M release name closed this week and we’re all awaiting the final name selection. Stay tuned to the openstack-dev mailing list for the final M name.

OpenStack Community Weekly Newsletter (June 12 – 19)

Built an App on OpenStack at QCon NY 2015

Developers building apps on top of OpenStack get more tutorials to play with. Everett Toews published abstract, slides and code from his talk at QCon in New York on how to get started building and deploying an application on OpenStack.

OpenStack Networking with Neutron: What Plugin Should I Deploy?

Nir Yechiel published a summary of the talk he gave at OpenStack Israel event on June 15th: what is a Neutron plugin, what plugins are available and how to choose one.

OpenStack’s Volume Backup Status

When working in the Cloud the idea of doing backups like in the old days may seen counter intuitive. After all, the main reasons for having backups are recovering data after it’s lost, by deletion or corruption, and recovering it from an earlier time, and you have those covered with fast volume snapshots and the use of fault tolerant back-ends like Ceph, that replicate data, for your volumes. So, why would you still need old school backups? Find out on Gorka Eguileor‘s post.

The Road to Tokyo

Reports from Previous Events

Relevant Conversations

Deadlines and Contributors Notifications

Security Advisories and Notices

Tips ‘n Tricks

Open Call for Proposals

Recently Merged Specs

Subject Owner Project
Track cinder capacity notifications XinXiaohui openstack/ceilometer-specs
Improve Install Guide Liberty RST spec Andreas Jaeger openstack/docs-specs
Add side-by-side comparison of v2 and v3 APIs Diane Fleming openstack/keystone-specs
[EDP] Allow editing job binaries Trevor McKay openstack/sahara-specs
[EDP] Allow editing datasource objects Trevor McKay openstack/sahara-specs
Minor grammar cleanup of enroll-node-state John L. Villalovos openstack/ironic-specs
libvirt: rename ‘parallels’ virt_type to ‘vz’ Maxim Nestratov openstack/nova-specs
Updates designate spec Domain properties Kanagaraj Manickam openstack/heat-specs
Add unit tests for Trove specs Nikhil Manchanda openstack/trove-specs
Service group spec re-proposed from kilo-backlog to liberty badveli_vishnuus openstack/neutron-specs
Add support for external resources Angus Salkeld openstack/heat-specs
Spec to remove the pipeline from the api server Chris Dent openstack/ceilometer-specs
service: Adds Windows Oslo Service Workers spec Claudiu Belu openstack/oslo-specs
Nested Quota Driver Vilobh Meshram openstack/cinder-specs
Symlinks in Swift Samuel Merritt openstack/swift-specs
Add “enroll” state to the state machine Dmitry Tantsur openstack/ironic-specs
Conditionally expose resources based on roles Pavlo Shchelokovskyy openstack/heat-specs
Conditionally expose resources based on services Pavlo Shchelokovskyy openstack/heat-specs
Add blueprint for tempest cli improvements David Paterson openstack/qa-specs
Dynamic pipeline configuration using file reloading Rohit Jaiswal openstack/ceilometer-specs
Sort instances if possible inside an host aggregate Jean-Daniel Bonnetot openstack/nova-specs
Move rearrange-schemas spec to implemented Ghanshyam Mann openstack/qa-specs
Spec for using a aggregation pipeline in MongoDB Ilya Tyaptin openstack/ceilometer-specs
Correct resource name for consolidate console API Alex Xu openstack/nova-specs
Hyper-V: Add storage QoS support Petrut Lucian openstack/nova-specs

Upcoming Events

Other News

OpenStack Reactions

Getting a token from keystone

Getting a token from keystone

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 Community Weekly Newsletter (June 5 – 12)

Five things every contributor should know about the OpenStack docs project

New docs contributors may be afraid of moving too fast and breaking things – but don’t worry, you can’t. A simpler markup language and a robust community of experienced, multilingual contributors make it even easier to find what you love and dive right in. Here are five key things you need to know about documentation but were probably afraid to ask.

How the cloud can cut red tape

The paperwork for opening a business or getting unemployment benefits often feels like a game of red-light/green-light. For every bit of progress, you get pushed back to collect more documents or show those same documents to a different agency. That’s where OpenStack comes in, says Victor Lagunes, CIO, office of the president of Mexico. About 18 months ago, the Mexican government started on a path to consolidate a staggering 4,000 federal websites for 6,500 services into a single portal to rule them all.

More Post-Vancouver Summaries

Relevant Conversations

Deadlines and Contributors Notifications

Security Advisories and Notices

Tips ‘n Tricks

Open Call for Proposals

Recently Merged Specs

Subject Owner Project
Implementation of remote FS driver based on rsync for libvirt Marian Horban openstack/nova-specs
Add Quota support for Barbican resources Dave McCowan openstack/barbican-specs
Add inband RAID configuration spec for liberty Ramakrishnan G openstack/ironic-specs
Allow ip6 server search for non-admin Jens Rosenboom openstack/nova-specs
Hyper-V: Add Fibre Channel support Petrut Lucian openstack/nova-specs
Add generic RAID configuration spec for liberty Ramakrishnan G openstack/ironic-specs
Remove v3 from nova code tree Alex Xu openstack/nova-specs
Be more explicit with our review policies. Michael Still openstack/nova-specs
Neutron API evolution strategy Salvatore Orlando openstack/neutron-specs
Creating initial Liberty install guide doc specs Karin Levenstein openstack/docs-specs
Fix a bunch of typos in approved liberty specs Joe Gordon openstack/nova-specs
remove pagination effort gordon chung openstack/ceilometer-specs
Introduce address scopes Carl Baldwin openstack/neutron-specs
Implement floating IPs using stateless NAT Carl Baldwin openstack/neutron-specs
Cells instance migration Andrew Laski openstack/nova-specs
Add event notification spec Christian Schwede openstack/swift-specs
flavor access create should check public/private jichenjc openstack/nova-specs
Add liberty priorities John Garbutt openstack/nova-specs
Add spec for transport key reference Ade Lee openstack/barbican-specs
Add ironicclient version caching Michael Davies openstack/ironic-specs
Enable spoofchk control for SR-IOV ports Roman Bogorodskiy openstack/neutron-specs
New nova API call to mark nova-compute down Tomi Juvonen openstack/nova-specs
Add Crypto/HSM MKEK Rotation Support (Light) John Wood openstack/barbican-specs
iPXE dynamic configuration Lucas Alvares Gomes openstack/ironic-specs
Bare Metal Trust Using Intel TXT Tan Lin openstack/ironic-specs
Supported messaging drivers policy Clint ‘SpamapS’ Byrum openstack/openstack-specs
Adding custom scenario tests Evgeny Sikachev openstack/sahara-specs
Generic image volume cache functionality Patrick East openstack/cinder-specs
Cinder internal tenant Patrick East openstack/cinder-specs
capacity-headroom XinXiaohui openstack/cinder-specs
Monasca resource plugin for Alarm and Notification Gary Duan openstack/heat-specs
Database and User Functions for Cassandra Petr Malik openstack/trove-specs
Updates to encryption spec Alistair Coles openstack/swift-specs
Add nodes tagging support Zhenguo Niu openstack/ironic-specs
Wake-On-Lan (WOL) power driver Lucas Alvares Gomes openstack/ironic-specs
CORS Support for OpenStack Michael Krotscheck openstack/openstack-specs
Create table publishing middleware Tim Hinrichs openstack/congress-specs
Datalog-aggregates Tim Hinrichs openstack/congress-specs
horizon-policy-abstraction spec zhang yali openstack/congress-specs
Cleanup ‘scheduled_at’ from instances table Sudipta Biswas openstack/nova-specs
Add support for shared volumes between guests Tobias Engelbert openstack/nova-specs
Removes contrib entry from Designate spec Kanagaraj Manickam openstack/heat-specs
MongoDB user management commands Matthew Van Dijk openstack/trove-specs
Configuration Groups for MongoDB Petr Malik openstack/trove-specs
Configuration Groups for Redis Petr Malik openstack/trove-specs
fix wrong title for OS-INHERIT Extension spec Guojian Shao openstack/keystone-specs
Introduce flavor framework for services mark mcclain openstack/neutron-specs
Use os-brick library Walter A. Boring IV (hemna) openstack/nova-specs
Federated domain identified by “id“ not “name“ Marek Denis openstack/keystone-specs
Removing JobExecutionArgument Table Ethan Gafford openstack/sahara-specs

Upcoming Events

Other News

OpenStack Reactions

Watching the rabbit event queue on an OpenStack cloud when spawning a VM

Watching the rabbit event queue on an OpenStack cloud when spawning a VM

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.

Technical Committee Highlights June 5, 2015

Welcome to this week’s highlights from the Technical Committee. Just like every other week, this has been quite a busy one for the community and the efforts to enhance our governance model keep moving forward.

The tc-approved-release tag has been approved

The tc-approved-release tag was mentioned in the last edition of these highlights. The discussions has moved a step forward and the first, basic, version of this tag has been approved. You can read the full version here. Initially, all projects that have the tag-integrated-release tag also get the tc-approved-release tag.

Compute kernel tag

A good part of the last meeting – from 20:07 to 20:38 – was spent discussing this tag and we’ll do the same in this post. Lets start by describing what this tag is trying to achieve.

The tag aims to define the minimum set of required projects to have a running OpenStack Compute deployment. The motivation behind this tag comes from the Kilo mid-cycle OPs meetup where some of the participants suggested that this is something the community should dictate. Although there’s no disagreement on how important and valuable this information is for the community, there seem to be different opinions about who should provide this information and how it should be provided. This means there are 2 questions that need to be answered in order to reach consensus on this matter:

Should the TC have an opinion on start here for this use case today?
If yes, How should this opinion be expressed/represented?

There were 2 versions of question number one. The previous version didn’t include the use case bit, which turned out being a deal breaker for several members of the technical committee. The use case clause indicates that the TC could express an opinion on starting points for different scenarios, such as compute, object-storage, or bare metal, instead of providing a single starting point for a specific use case. Some of the current opinions are:

The information provided by this tag has nothing to do with the governance
The TC should know how to answer questions like: “What’s the minimum required set to get OpenStack running?” If the TC can’t, who else is going to do it?
The TC could have an opinion on different starting points but it should not dictate a one-and-only entry point.

The TC voted on the first question and the results were in favor for the TC having an opinion on this matter. Question number 2, however, remains open and it’ll likely be discussed in future meetings. If you have an opinion on how these starting points should be communicated, please do provide them on this review.

i18n is now an OpenStack Project Team

The group behind i18n has taken a step forward in their organization and they are now an OpenStack Project Team. The TC and the community are excited to have an official i18n team. Their mission is “To make OpenStack ubiquitously accessible to people of all language backgrounds” and we fully support them.

Consideration of the Packaging team proposal

The TC also discussed a proposal adding distribution packaging to OpenStack. We decided that the packaging team proposal should be set to Work In Progress until the plan is more fully described with infrastructure considerations. There’s a lot of activity on the mailing list so please join in if you’re interested in the outcome.

Potential release cycle overhaul

Please take a look at the mailing list discussions for changing the release cycles for certain projects such as Ironic.

In closing, for a bit of fun take a look at the M names proposed for the next release cycle including Japanese characters inline. We’re looking forward to the vote.

OpenStack Community Weekly Newsletter (May 29 – June 5)

Containers and OpenStack: here’s what you need to know

Interview with Adrian Otto, a principal architect at Rackspace, is the project technical lead (PTL) for Magnum, an API service developed by the OpenStack containers team for OpenStack to make container management tools such as Docker and Kubernetes available as first-class resources in OpenStack. Magnum officially joined the OpenStack project list upon approval by a unanimous vote by the Technical Committee in March 2015.

What building Legos can teach you about open source

If you want to build a gas station next to a children’s playground, fireworks are pretty much guaranteed. That not-in-my-neighborhood face-off was one of the issues hashed out in a recent OpenStack Upstream Training session where about 50 participants split into teams building Lego sets.

Travel grants bring global community members to OpenStack Summit

Turns out there’s nothing like working together in person to push a cloud project forward. To help make that valuable face time happen, the OpenStack Foundation funded the travel and hotel accommodations for 21 men and 7 women who are key contributors to attend the OpenStack Summit Vancouver.

Neutron RFE Process

Starting with the development of the Juno release, the Neutron project moved to using a specs repository similar to how other projects were using them. Kyle Mestery, Neutron’s PTL, reflects on the fact that the process at best, lengthened the pipeline we had in place to gate the incoming feature fire-hose. At worst, it turned off potential committers. Neutron’s team is implementing a new process meant to allow users to express their desires for new features using Launchpad.

More Post-Vancouver Summaries

Relevant Conversations

Deadlines and Contributors Notifications

Security Advisories and Notices

  • None

Tips ‘n Tricks

Open Call for Proposals

Recently Merged Specs

Subject Owner Project
fix wrong title for OS-INHERIT Extension spec Guojian Shao openstack/keystone-specs
Introduce flavor framework for services mark mcclain openstack/neutron-specs
Use os-brick library Walter A. Boring IV (hemna) openstack/nova-specs
Federated domain identified by “id“ not “name“ Marek Denis openstack/keystone-specs
Removing JobExecutionArgument Table Ethan Gafford openstack/sahara-specs
Spec for pre-signed URLs Flavio Percoco openstack/zaqar-specs
Add support for missing features in zaqarclient v1.1 Doraly Navarro openstack/zaqar-specs
Tests refactoring spec Thomas Herve openstack/zaqar-specs
Remove Liberty Placeholder Kiall Mac Innes openstack/designate-specs
Add a backlog folder Flavio Percoco openstack/zaqar-specs
Fix references syntax for correct conversion into html Oleksii Zamiatin openstack/oslo-specs
MongoDB database management commands Matthew Van Dijk openstack/trove-specs
Configuration Groups for Cassandra Petr Malik openstack/trove-specs
Add backup and restore to the Redis datastore Peter Stachowski openstack/trove-specs
Update Ironic spec URL refs to specs.openstack.org Naohiro Tamura openstack/ironic-specs
Spec for graduating reports Davanum Srinivas (dims) openstack/oslo-specs
Neutron QoS API Extension Sean M. Collins openstack/neutron-specs
Explain how to adopt a backlog spec Joe Gordon openstack/nova-specs
Add new boot interface in Ironic Ramakrishnan G openstack/ironic-specs
Add spec approval rules to readme Michael Still openstack/nova-specs
Property Group Kanagaraj Manickam openstack/heat-specs
Drop incubating theme from docs Joe Gordon openstack/barbican-specs
Add open-iscsi transport support to brick Anish Bhatt openstack/cinder-specs
Adopt oslo guru meditation report to cinder wanghao openstack/cinder-specs
Backup and Restore for Cassandra Petr Malik openstack/trove-specs


Upcoming Events

Other News

OpenStack Reactions

Unexpected hiccup before the release

Unexpected hiccup before the release

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 Community Weekly Newsletter (May 8 – 29)

OpenStack users share how their deployments stack up

Some of OpenStack’s founding projects — including Nova, Keystone, Glance, Horizon and Cinder — continue to be the most popular. That may be changing, however. For starters, the inclusion of bare-metal provisioning project Ironic in the integrated release led to an increase across all deployment stages, including production, test and running a proof-of-concept (POC). Other projects, including Heat, Ceilometer, Swift and Trove, are also gaining in adoption, according to the recent User Survey.

OpenStack application developers share insights

Application developers working with OpenStack know what they want. Most are looking for clear, accurate documentation with emphasis on detailed working examples so they can get their jobs done. That’s one of key takeaways from the fifth consecutive survey conducted by the User Committee.

How to get more women involved in tech? Communication, leadership and mentors

Whether the women considering the problem were developers, engineers or marketers, they all pinpointed that communication, leadership and mentorship were fundamental to getting more women involved.

Think FICO is a credit scoring company? Nope: it’s about large-scale analytics

Americans have been counting on FICO to measure their credit worthiness since the 1980s, but the San Jose, California-based company has much a farther reach.

Post-Vancouver Summaries

Relevant Conversations

Deadlines and Development Priorities

Security Advisories and Notices

Tips ‘n Tricks

Upcoming Events

Other News

OpenStack Reactions

Life of an OpenStack contributor in Animated GIF the summit session (Vancouver 2015) will make you laugh out loud

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.

Technical Committee Highlights May 29, 2015

Welcome back from the summit. A huge part of OpenStack’s community gathered together in Vancouver for a week full of brainstorms, problem solving and planning for the next 6 months. So did the Technical Committee and here are the highlights of last week and this week’s meeting.

Design Summit


Joint Board and TC meeting

We held a joint Board and TC meeting Sunday afternoon. The DefCore definition has been updated and it now includes the Kilo release, YAY! With the changes, interoperability testing includes:

  • Auth operations within the Identity API; however identity management operations will not be considered designated sections because they are controlled by policies.
  • Management operations for floating IPs through the Compute API.

The testing means that we have concrete evidence of interoperability for OpenStack clouds.

As a community, we have to make a decision about nova-network or neutron API calls and compatibility for interop in the coming six months. Lots of great discussion happened at the Summit, and one way forward is through documenting how to keep floating IP call compatibility by showing how to use ports in the Neutron API to be equivalent to elastic floating IP lists. Stay tuned as we write up more details in a doc near you.

Diversity working group approved to go and set up a mission. This is uncharted territory but we want to chart it as other cloud organizations and open source groups look to us to pave the way.

Tags, tagging, tagification

As part of completing the list of base tags for OpenStack, the TC often has to discuss whether some of them make sense or not. The tags currently under discussion are: tc-approved release and kernel:compute.

Tag (rather confusingly) named tc-approved-release
This tag mostly exists to suffice one of the requirements imposed by the Foundation bylaws. It serves to indicate that the Technical Committee has included a project in the “OpenStack TC Approved Release”, which indicates projects that are suitable to be included in the “Trademark Designated OpenStack Software”. Although the name might be confusing and not sexy, it serves the sole purpose of sufficing the bylaws requirements.Check the proposed change for more info.
Tags named kernel:compute (exciting?) or use-case:basic-compute (boring?)
This tag is meant to indicate the set of services that are required to have a minimum compute deployment. We’re having long discussions around this tag with community members and each other on the TC. The discussions go from whether it is useful at all, what the scopes and limits of this tag are and whether it sends the right message or not. You can follow some of these discussions on the review itself.

Cross-project sessions

The Technical Committee whittled down the list of proposed cross-project sessions to 14 sessions, and we want to report back on these sessions.

The single network stack session has a part two as well, where the discussion came up with the priority to test Linux Bridge on DevStack as well as document the port reuse example that gives more compatible floating IP features. Floating IP quotas will not apply to this situation so people will be able to burn as many public IPs as their port quota allows, but it seems like this documentation is sorely missed right now.

Stable releases have been available with a tag, such as 2015.1, since the project’s inception. But at a cross project session we decided that the current tagged releases are not more stable or tested than any other, and the stable branches are actually the ones we would like deployers to use as reference. We are dedicated to stability and trust of those branches. Please read more and reply on http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html with any questions.

We had good forward progress on the service catalog and CORS support in OpenStack. The wiki page has all the Etherpads from sessions if you want to deep dive on those sessions.

Latest news from last TC meeting

We voted to give Scott Moser, maintainer of Cirros, Active Technical Contributor (ATC) status for his work on the lightweight image and operating system we use consistently for launching and testing VMs.

The chef project was proposed as an OpenStack project and the TC voted it in. We still want to see evidence of being an OpenStack project, but moving their open design discussions to the OpenStack-dev mailing list is the right step.

We also passed a resolution to use UTC always. Now, some of us felt this was heavy-handed, but once we learned of the risk of having to restart an election (or a candidate missing a deadline due to confusion on the time or date of election deadlines), we agreed to pass it as a resolution.

Also we have a process for gathering potential release names that start with M and are near the summit location. Monty Taylor is the name coordinator, so look for the list of potential names on Monday, June 1. The next release is less than five months away, October 15, 2015.

A subteam from the TC is working on the OpenStack Project Team Guide June 18-19 in a remote work session and all are welcome to help.

The TC is also looking to provide deep-dive into troublesome issues with teams and help with resolutions. We’re also looking into starting a basic design tenants team as well as cross-project team to improve activity around cross-project specs and the cross-project meeting.