The content below is taken from the original (Technical Committee Highlights June 13, 2016), to continue reading please visit the site. Remember to respect the Author & Copyright.

It has been a while since our last highlight post so this one is full of updates.

New release tag: cycle-trailing

This is a new addition to the set of tags describing the release models. This tag aims to allow specific projects for doing releases after the OpenStack release has been cut. This tag is useful for projects that need to wait for the “final” OpenStack release to be out. Some examples of these projects are Kolla, TripleO, Ansible, etc.

Reorganizing cross-project work coordination

The cross project team is the reference team when it comes to reviewing cross project specs. This resolution grants the cross project team approval rights on cross-project specs and therefore the ability to merge such specs without the Technical Committee’s intervention. This is a great step forward on the TC’s mission of enabling the community to be as autonomous as possible. This resolution recognizes reviewers of openstack-specs as a team.

Project additions and removals

– Addition of OpenStack Salt: This project brings in SaltStack formulas for installing and operating OpenStack cloud deployments. The main focus of the project is to setup development, testing, and production OpenStack deployments in easy, scalable and predictable way.

– Addition of OpenStack Vitrage: This project aims to organize, analyze and visualize OpenStack alarms & events, yield insights regarding the root cause of problems and deduce their existence before they are directly detected.

– Addition of OpenStack Watcher: Watcher’s goal is to provide a flexible and scalable resource optimization service for multi-tenant OpenStack-based clouds.

– Removal of OpenStack Cue: Cue’s project team activity has dropped below what is expected of an official OpenStack project team. It was therefore removed from the list of official projects.

Recommendation on location of tests for DefCore verification

A new resolution has been merged in which it’s recommended for the DefCore team to use Tempest’s repository as the central repository for verification tests. During the summit, 2 different options were discussed as possible recommendations:

• Use the tests within the Tempest git repository by themselves.
• Add to those Tempest tests by allowing projects to host tests in their tree using Tempest’s plugin feature.

By recommending using the Tempest repository, the community will favor centralization of these tests, it’ll improve the collaboration on DefCore matters and it’ll also improve the consistency across the tests used for API verification.

Mission Statements Updates

On one hand Magnum has narrowed its mission statement after discussing it at the Austin summit. The team has decided Magnum should focus on managing container orchestration engines (COE) rather than managing containers lifecycle as well. On the other hand, Kuryr has expanded its mission statement to also include management of storage abstractions for containers.

Expanding technology choices in OpenStack projects

On the face of it, the request sounds simple. “Can we use golang in OpenStack?” asked of the TC in this governance patch review.

It’s a yes or no question. It sets us up for black and white definitions, even though the cascading ramifications are many for either answer.

Yes means less expertise sharing between projects as well as some isolation. Our hope is that certain technology decisions are made in the best interest of our community and The OpenStack way. We would trust projects to have a plan for all the operators and users who are affected by a technology choice. A Yes means trusting all our projects (over fifty-five currently) not to lose time by chasing the latest or doing useless rewrites, and believing that freedom of technology choice is more important than sharing common knowledge and expertise. For some, it means we are evolving and innovating as technologists.

A No vote here means that if you want to develop with another language, you should form your new language community outside of the OpenStack one. Even with a No vote, projects can still use our development infrastructure such as Mailing Lists, Gerrit, Zuul, and so on. A No vote on a language choice means that team’s deliverable is simply outside of the Technical Committee governance oversight, and not handled by our cross-project teams such as release, doc, quality. For the good of your user base, you should ensure all the technology ramifications that a yes vote would, but your team doesn’t need to work under TC oversight.

What about getting from No to Yes? Could it mean that we would like you to remain in the OpenStack community but please plugin parts that are not considering the entire community while being built.

We’ve discussed additional grey area answers. Here is the spectrum:

• Yes, without limits.
• Yes, but within limits outlined in our governance.
• No, remember that it’s perfectly fine to have external dependencies written in other languages.
• No, projects that don’t work within our technical standards don’t leverage the shared resources OpenStack offers so they can work outside of OpenStack.

We have dismissed the outer edge descriptions for Yes and No. We continued to discuss the inner Yes and inner No descriptions this week, with none of the options being really satisfactory. After lots of discussion, we came around to a No answer, abandoning the patch, while seeking input for getting to yes within limits.

Basically, our answer is about focusing on what we have in common, what defines us. It is in-line with the big-tent approach of defining an “OpenStack project” as being developed by a coherent community using the OpenStack Way. It’s about sharing more things. We tolerate and even embrace difference where it is needed, but that doesn’t mean that the project has to live within the tent. It can be a friendly neighbour rather than being in and resulting in breaking the tent into smaller sub-tents.