OpenStack Queens is Officially Released!

Congratulations to all the teams who contributed to this release! Release notes of different projects for Queens are available [0] and a list of projects [1] that still need to approve their release note patches!

Pros and Cons of face-to-face Meetings

Some contributors might not be able to attend the PTG for various reasons:

Health issues

Privilege issues (like not getting visa or travel permits)

Caretaking responsibilities (children, other family, animals, plants)

Environmental concerns

There is a concern if this is preventing us from meeting our four opens [1] if people are not able to attend the events.

The PTG sessions are not recorded, but there is a super user article on how teams can do this themselves [0]. At the PTG in Denver, the OpenStack Foundation provided bluetooth speakers for teams to help with remote participation.

Consensus is this may not be trivial for everyone and it could still be a challenge for remote participants due to things like audio quality. Some people at the PTG in Dublin due to the weather had to participate remotely from their hotel room and felt it challenging to partipate.

Vancouver Community Contributor Awards

The Community contributor awards gives recognition to those that are undervalued, don’t know they’re appreciated, bind the community together, keep things fun, or challenge some norm. There are a lot of people out there that could use a pat on the back and affirmation that they do good work in the community.

Nomination period is open now [0] until May 14th. Winners will be announced in feedback session at Vancouver.

Release Naming For S – time to suggest a name!

It’s time to pick a name for our “S” release! Since the associated Summit will be in Berlin, the Geographic location has been chosen as “Berlin” (state). Nominations are now open [0]. Rules and processes can be seen on the Governance site [1].

Final Queens RC Deadline

Thursday 22nd of April is the deadline for any final Queens release candidates. We’ll enter a quiet period for a week in preparation of tagging the final Queens release during the PTG week. Make sure if you have patches merged to stable/queens that you propose a new RC before the deadline. PTLs should watch for a patch from the release management team tagging the final release. While not required, an acknowledgement on the patch would be appreciated.

Do Not Import oslo_db.tests.*

Deprecations were made on oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase. In a patch [0], and assumption was made to that these should be imported from oslo_db.tests.sqlalchemy. Cinder, Ironic and Glance have been found with this issue [1].

Unfortunately these were not prefixed with underscores to comply with naming conventions for people to recognize private code. The tests module was included for consumers to run those tests on their own packages easily.

PTG Bot HOWTO for Dublin

The third PTG is an event where topics of discussion are loosely scheduled in tracks to maximize the attendee productivity. To keep track of what’s happening currently we have an event schedule page [0]. Below are some helpful discussions in using PTG bot:

Track Leads

Track leads will be able issue various commands [1] in irc channel #openstack-ptg:

#TRACK now <what’s being discussed>

example: #swift now brainstorming improvements to the ring.

Cross project interactions #TRACK now <what’s being discussed with other #TRACK>:

#nova now discussing #cinder interactions

What’s next #TRACK next <what will be discussed>:

#api-sig next at 2pm we’ll be discussing pagination woes

Clear all now and next entries for a track #TRACK clean:

#ironic clean

Booking Reservable Rooms

Reservable rooms and what’s being discussed works the same with it showing on the event schedule page [0].

Different set of commands:

Get the slot codes with the book command:

#TRACK book

#TRACK book <slot_code>

example: #relmgt book Coiste Bainisti-MonP2

Any track can book additional space. These slots are 1 hour and 45 minutes long. You can ask ttx, diablo_rojo or #openstack-infra to add a track that’s missing. Keep in mind various teams will be soley relying on this for space at the PTG.

PTL Election Results and Conclusions

PTL election is over and the results are in [0]! Congrats to returning and new PTLs!

There were three elections that took place:

Kolla [1]

Mistral [2]

Quality Assurance [3]

On the statistics side, we renewed 17 of the 64 PTLs, so around 27%. Our usual renewal rate is more around 35%, but we did renew more at the last elections (40%) so this is likely why we didn’t renew as much as usual this time. Much thanks to our election officials for carrying out this important responsibility in our community!

Election Process Tweaks

Discussions have started with ways to improve our election process. Current scripts in place have become brittle that are needed for governance documentation building that use gerrit lookup functions. Election officials currently have to make changes to an exception file [0] when email address with foundation accounts don’t match gerrit.

Comments, concerns and better ideas are welcome. The plan is to schedule time at the PTG to start hacking on some of those items so feedback before then would be appreciated by your election officials!

Dublin PTG Schedule is Up

PTG schedule is available [0]. A lot of rooms are available Monday/Tuesday to discuss additional topics that take half a day and can be requested [1]. For small things (90 min discussions) we can book them dyncamically during the event with the new PTG bot features. Follow the thread for updates to the schedule [2].

Last Chance for PTG Dublin Tickets

PTG tickets for Dublin were sold out this week, and the Foundation received many requests for more tickets. Working with the venue to accommodate the extra capacity, every additional attendee incrementally increases costs to $600. It’s understood the importance of this event and the need to have key team members present, so the OpenStack Foundation has negotiated an additional 100 tickets and will partially subsidize to be at sold at $400 [0].

As a general planning guideline, if a visa is needed, a foreign traveler should apply for his or her visa as soon as possible, preferably no later than 60 days before the travel date.

Travel Support Program

The Travel Support Program (TSP) aims to facilitate participation of key contributors to the OpenStack Summit by covering the costs for their travel and accommodations. The grants will cover a combination of flights, accommodation, and access pass to the Summit. More details here.

All contributors to OpenStack (developers, documentation writers, organizers of user groups around the world, Ask moderators, speakers, translators, etc) are invited to submit a request. You can apply by filling out this form.

More Questions?

Got any other questions about the Summit? There is an excellent FAQ here.

The Project Teams Gathering (PTG) in Dublin February 26 – March 2. It’s an event for anyone who self-identifies as a member in a specific given project team as well as operators who are specialists on a given project and willing to spend their time giving feedback on their use case and contributing their usage experience to the project team.

Upcoming Industry Events

FOSDEM

The Foundation will be present at FOSDEM in Brussels, February 3-4 2018.

Community Goals for Rocky

So far one goal has been proposed by Kendall Nelson for migrating to Storyboard. It was agreed to postpone the goal until the S cycle, as it could take longer than six months to achieve. There is a good backlog of goals [0], just no champions. It’ll be bad for momentum if we have a cycle with no community wide goal.

PTG Post-lunch Presentations

Feedback received from past PTG session(s) was the lack of situational awareness and missed opportunity for “global” communication at the event. In Dublin we’d used the end of the lunch break to for communications that could be interesting to OpenStack upstream developers and project team members. The idea is not to find a presentation for everyday, but if we find content that is generally useful. Interesting topics include general guidance to make the most of the PTG weeks (good Monday content), development tricks, code review etiquette, new library features you should adopt, lightning talks (good Friday content). We’d like to keep the slot under 20 minutes. If you have ideas please fill out this etherpad [0] in a few weeks.

The Foundation is excited to announce Kata Containers. This project unites the security advantages of virtual machines with the speed and manageability of containers for running container management tools directly on bare metal without sacrificing workload isolation. Kata Containers delivers increased performance, faster boot time and cost efficiencies. Kata Containers will have its own governance, community and communication channels.

To find out more and get involved:Sign up for Kata Containers updates atkatacontainers.io

The Scientific Working Group has updated the Crossroads of Cloud and HPC: OpenStack for Scientific Research. Version 2 of the popular book details multiple enhancements made to OpenStack for HPC workloads over the past year and added several new in-depth case studies on how OpenStack supports radio astronomy, bioinformatics, cancer and genome research and more. Read or order the book at https://www.openstack.org/science/ to find out exactly how OpenStack allows researchers to spend less time managing infrastructure and more time on research that matters. To learn more or get involved in the Scientific Working Group, visit https://wiki.openstack.org/wiki/Scientific_SIG

THANK YOU!

It has been a fantastic 2017!!! Thank you to all community members for your industrious efforts and contributions! Wish you all a Happy Holiday break and a great New Year.

Switching to Longer Development Cycles

Our self-imposed rhythm no longer matches our natural pace. Our elections, feature freezes feel like they’re around the corner, and due to that, we’re losing time from them, as multiple people have stated. The pace was designed around more people contributing full time to OpenStack, but lately, we have composite jobs, or were participating in multiple communities (which is great!).

It means:

One OpenStack coordinated release per year.

Maintain one stable branch per year.

Elect PTLs once a year.

One set of community goals per year.

One PTG per year.

Any project that still wants to release often can use the cycle-with-intermediary release model [0]. At a minimum, we’ll release once a year. Teams can choose to revive midcycle if they need to meet more than the one PTG each year. We’ll have more time for community-wide goals, so we will have more time to complete or even set more ambitious goals.

This doesn’t simplify upgrades. While upgrading every year is incrementally better than being forced to upgrade every 6 months. The real solution is better support for skipping releases.

It also doesn’t give us LTS. The cost of maintaining branches is not really due to the number of them in parallel, it’s due to the age of the oldest one. The real solution here is being discussed by the (still forming) LTS SIG. Extending stability periods is per-project at this point, and the proposal has yet to address a coordinated stability period.

We’re doing a year because of the way the events are organized. It’s suggested to start for the Rocky release and have the single PTG in 2018 in Dublin. The release team is opening the discussion to the community, and the TC will give a final decision.

Various cons were expressed, like this causing a rush to get in code at the end of a release to avoid having to wait an entire year. Projects are also forced to do compatibility support for versioned APIs, config files, etc since projects would be unable to drop compatibility in an intermediate release. Projects like Grenade will have to support the cases of some projects doing intermediate releases, and those doing yearly.

For the people that spend 20% of their time contributing to OpenStack, it has been voiced that it takes time to get a feature merged and the current cycle makes it impossible. This longer development cycle could help with allowing more time for those people. Various people expressed that we should be looking at the root cause of helping our part-time contributors, as the length of the cycle is unlikely the cause. People who can only contribute 20% of their time are also likely to deal with rebase conflicts, instead of focusing on their code.

Having a year could also impose having intermediate releases so specifications that can have multiple times a year to be approved. If that’s the idea, however, then it’s causing stress on the core team by having to match these precise schedules, in which the proposal was aiming to ease. It was a concern that this more solves the problem of giving more opportunities to people to get their spec/new feature considered.

This topic has also been brought up by various times in the past. Someone noted Daniel Berrange’s thread [1]

Zuul Dashboard Available

In addition to the Zuul dashboard [0] showing the “Status”, there are additional tabs added. “Jobs” page shows a list of all jobs in the system and their descriptions. The “Builds” page lists the most recent runs. You can query pipeline, job, and project.

Security SIG

Following previous mailing list discussions [0], the Security Project will be changing into a Special Interest Group (SIG). SIGs have shown to be a good match for the activity the group does around a topic or practice that spans around the community of developers, operators, and users. The group will continue to manage and care for the Security Guide, OSSNs, Bandit, Thread Reviews, Syntribos as well as encourage and incubate new security projects. The group will continue to work with the VMT and will keep a Sec-core group for launchpad that can work with the embargoes issues.

Cycle Highlights Reminder

As we get closer to Queens-3 and our final RCs, a reminder is given about the new ‘cycle-highlights’ that has been added to deliverable info. Background of why this was added, some PTLs were being pinged multiple times every release cycle by various people like journalists, product manager and other to compile the same information. To mitigate that, we have a way to capture highlights as part of the release. This will give basic information, but not as a complete marketing message.

This is done in the openstack/releases repository in the deliverables/queens/$PROJECT.yaml file formatted like so:

cycle-highlights:

– Introduced new service to use the unsed host to mine bitcoin.

We have three different places that document activities for three different audiences:

Dublin PTG Format

We will continue themes as we did in Denver (Monday-Tuesday), but shorter times like half days. Flexibility is added for other groups to book the remaining available rooms in 90-min slots on-demand driven by the PTG Bot (Wednesday-Friday.

First Contact SIG

A wiki has been created for the group [0]. The group is looking for intersted people being points of contact for newcomers and what specified time zones. Resource links like contributor portal, mentoring wiki, Upstream Institute, outreachy are being collected on the wiki page. A representative from the operators side to chair and represent would be good.

Self-healing SIG created

Adam Spiers announced the formation of a SIG around self-healing. Its scope is to coordinate the use and development of several OpenStack projects which can be combined in various ways to manage OpenStack infrastructure in a policy-driven fashion, reacting to failures and other events by automatically healing and optimising services.

Proposal for a QA SIG

A proposal to to have a co-existing QA special interest group (SIG) that would be a place for downstream efforts to have a common place in collaborating and sharing tests. Example today the OPNFV performs QA on OpenStack releases today and are actively looking for opportunities to share tools and test cases. While a SIG can exist to do some code, the QA team will remain for now since there are around 15 QA projects existing like Tempest and Grenade.

Improving the Process for Release Marketing

Collecting and summarizing “top features” during release time is difficult for both PTL’s and Foundation marketing. A system is now in place for PTL’s to highlight release notes [0]. Foundation marketing will work with the various teams if needed to understand and make things more press friendly.