The content below is taken from the original (OpenStack Developer Mailing List Digest July 23 to August 5), to continue reading please visit the site. Remember to respect the Author & Copyright.

Equal Chances For All Projects

A proposal [1] in the OpenStack governance repository that aims to have everything across OpenStack be plugin based, or allow all projects access to the same internal APIs.
Some projects have plugin interfaces, but also have project integrations in tree. Makes it difficult to see what a plugin can, and should do.
With the big tent, we wanted to move to a flatter model, removing the old integrated status.
Examples:
- Standard command line interface or UI for setting quotas, it’s hard for projects that aren’t Nova, Neutron or Cinder.
  - Quotas in Horizon for example are set in “admin → quotas”, but plugins can’t be in here.
  - OpenStack Client has “openstack quota set –instances 10” for example.
  - Steve Martinelli who contributes to OpenStack Client has verified that this is not by design, but lack of contributor resources).
- Tempest plugins using unstable resources (e.g. setting up users, projects for running tests on). Projects in tree have the benefit of any change having to pass gate before it merges.
  - Specification to work towards addressing this [2].
  - The stable interface still needs work work in increasing what it exposes to plugins. This requires a bit of work and is prioritized by the QA team.
    - All tests in Tempest consume the stable interface.
  - Since a lot of plugins use the unstable interfaces, the QA team is attempting to maintain backwards compatibility until a stable version is available, which is not always an option.
  - Tempest.lib [3] is what’s considered the “stable interface”
Given the amount of in progress work for the examples given, there doesn’t seem a disagreement with the overall goal to warrant a global rule or policy.
An existing policy exists [4] with how horizontal teams should work with all projects.
Full thread and continued thread

Establishing Project-wide Goals

An outcome from the leadership training session that members of the Technical Committee participated in was setting community-wide goals for accomplishing specific technical tasks to get projects synced up.
There is a change to the governance repository [5] that sets the expectations of what makes a good goal and how teams are meant to approach working on them.
Two goals proposed:
- Support Python 3.5 [6]
- Switch to Oslo libraries [7]
The Technical Committee wants to set a reasonable number of small goals for a release. Not invasive top-down design mandates that teams would want to resist.
- Teams could possibly have a good reason for not wanting or being able to fulfill a goal. It just needs to be documented and not result in being removed from the big tent.
Full thread

API Working Group News

Cinder is lookig into exposing resource capabilities.
- Spec [8]
- Patch [9]
Guidelines under review:
- Beginning set of guidelines for URIs [10]
- Add description of pagination parameters [11]
Full thread

Big Tent?

Should we consider the big tent is the right approach because of some noticed downsides:
- Projects not working together because of fear of adding extra dependencies.
- Reimplementing features, badly, instead of standardizing.
- More projects created due to politics, not technical reasons.
- Less cross-project communication.
- Operator pain in assembling loose projects.
- Architectural decisions made at individual project level.
Specific examples:
- Magnum trying not to use Barbican.
- Horizon discussions at the summit wanting to use Zaqar for updates instead of polling, but couldn’t depend on a non-widely deployed subsystem.
- Incompatible virtual machine communication:
  - Sahara uses ssh, which doesn’t play well with tenant networks.
  - Trove uses rabbit for the guest agent to talk back to the controller.
The overall goal of big tent was to make the community more inclusive, and these issues pre-date big tent.
The only thing that can really force people to adopt a project is DefCore, but that comes with a major chicken and egg problem.
What’s not happening today is a common standard that everything can move towards. Clint Byrum’s proposal on an Architecture working group might be a way forward.
The Technical Committee is a balancing act of trying to provide this, but not interfere too much with a project in which members may not have specific experience with the project’s domain.
Sahara has had some success with integration with other projects.
- Kilo/Liberty integrating with Heat for deploying clusters.
- Liberty/Mitaka integrated Barbican.
- Using Manila shares for datasources.
- Liberty/Mitaka added Sahara support in OpenStack Client.
- In progress, support with Designate.
Full thread