OpenStack Developer Mailing List Digest July 23 to August 5

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.
  • 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


[1] –

[2] –

[3] –
[4] –

[5] –

[6] –

[7] –

[8] –

[9] –

[10] –

[11] –

Leave a Reply

Your email address will not be published. Required fields are marked *