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”
- Standard command line interface or UI for setting quotas, it’s hard for projects that aren’t Nova, Neutron or Cinder.
- 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:
- 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:
- 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] – http://bit.ly/2b8ozH8
[2] – http://bit.ly/2b8oB4N
[3] – http://bit.ly/2b8nTBC
[4] – http://bit.ly/2b8pJ8w
[5] – http://bit.ly/2b8oSS2
[6] – http://bit.ly/2b8pk6a
[7] – http://bit.ly/2b8nG1l
[8] – http://bit.ly/2b8oNxN
[9] – http://bit.ly/2b8oC92
[10] – http://bit.ly/2b8oUt8
[11] – http://bit.ly/2b8pvyn