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.

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.

OpenStack Reactions

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.

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:

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.

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.

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.

OpenStack Reactions

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.

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.

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.

Other News

OpenStack Reactions

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.

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.

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.

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.

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.

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.

Other News

OpenStack Reactions

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.

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.

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.

Other News

OpenStack Reactions

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.

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.

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.

Your blueprint for your volume driver is submitted and approved (mark your blueprint as pending approval to get PTL’s attention)

Your volume driver code is posted to gerrit and passing gate tests

Your volume driver code gerrit review page has results posted from your CI, and is passing. Keep in mind that your CI must continue running in order to stay in the release. This also includes future releases

You meet all of the above at least by June 12th. This is to discourage late code submissions. Reviews can take time. Merges can also be very difficult late in the milestone due to the OpenStack Gate testing being very full. In the past we have seen gate wait times take a whole day. Do yourself a favor and don’t wait.

To be clear:

Your volume driver submission must meet all the items before we review your code. If not, you’ll have to submit your volume driver in the M release

If your volume driver is submitted after Liberty-1, expect me to reference this email and we’ll request the volume driver to be submitted in the M release

Even if you meet all of the above requirements by June 12th, it is not guanranteed that your volume driver will be merged by June 19th You still need to address all review comments in a timely manner and allow time for gating testing to finish

This does not include backup drivers

This does not include connector drivers in os-brick. This will be a separate discussion.

Based on multiple inputs from the openstack-dev mailing list, we’ve discovered we, the TC, need to level up our communications. We have identified two TC members to take on the communications plan, Anne Gentle (that’s me!) and Flavio Percoco. See below for details of the plan, and thanks for reading the first post in the revitalized series.

Welcome and thanks

After the TC elections were complete and validated, we said goodbye to Vish Ishaya, Devanandra van der Veen and Michael Still, and we welcomed new TC members Robert Collins, Jay Pipes, Dean Troyer and Flavio Percoco. The TC voted for Theirry Carrez to continue as TC chair for running the meetings and keeping the TC patch backlog reviewed and organized.

Summit preparation and cross-project track

A subteam worked through the 28 proposals for the cross-project track at the summit to fit into 14 available fishbowl rooms. Doug Hellman then presented it to the TC and we approved it for him to then apply his “note-cards-on-the-floor schedule resolution algorithm” to fit them into available time slots. Those have been pushed to sched at libertydesignsummit.sched.org.

Communication plan

Our goals for communicating about TC activity are to inform both the electorate and the wider community about decisions made, directions pointed, or guidance given through the OpenStack Technical Committee. We’ll use regular posts to the OpenStack Blog, pointers to the post in the weekly Community mailing list, and the feed to http://planet.openstack.org to issue regular communications.

We’ll continue to listen on the openstack-dev mailing list for any issues that come up, and use patches to the governance repo to shape the agenda each week. The final decisions are published to http://governance.openstack.org. Let us know if you envision any additional channels posting to the openstack-dev mailing list. While we did also consider a Twitter account for the TC, we won’t use a common account to avoid splitting attention across too many channels.

New project team guide

In the spirit of replacing aging wiki pages and oral tradition, a small team is tackling writing a project team guide. When we say “be an OpenStack team” we need to be specific about the meaning, processes, releases, and be able to point to documentation that defines our culture and expectations. Jim Blair, Flavio Percoco, Doug Hellman, and Thierry Carrez have agreed to start this effort.

Repository patches policy

Recently the TC decided to keep the repo list tidy by allowing the TC chair to push through basic listing changes proposed by a Project Team Lead (PTL) to their own projects. The agreement is to skip discussing repo additions in the Tuesday TC meeting and instead, let the patches be viewed for at least one week. Then, as long as there is no -1 from a TC member that may need discussion, the TC chair can approve them if the changes have PTL +1 and no TC member -1 by then.

Agenda timing

The process for getting an item considered for the TC meeting agenda had been documented as being proposed “at least 4 business days before meeting,” but now that items are proposed to Gerrit, Thierry proposed changing the agenda schedule to better match the way we work now. We all agreed we can consider a change TC meeting material if posted before 0800 UTC Friday.

Tags, tagging, and marking

We managed to time-box large, expansive discussions about reviews for tags to help define a “tc-approved-release” tag as well as a “compute-kernel” tag. We didn’t go into the discussions expecting resolution, and with the Summit coming up next week, we just wanted to hear more from each other on each topic in real-time, outside of the patch review itself. For the “tc-approved-release” tag, it is meant to embody the Technical Committees responsibility under the bylaws of the OpenStack Foundation. The “compute-kernel” tag is intended to indicate which projects are essential to a basic compute use case. In fact, we even discussed changing the tag name to include use-case. At this point, it’s probably best to read the logs from the meeting and follow along the reviews, as we made no conclusions.

We’re all looking forward to a great week in Vancouver. Thanks for the ongoing input, and keep it coming.