The content below is taken from the original (OpenStack Developer Mailing List Digest December 10- 16), to continue reading please visit the site. Remember to respect the Author & Copyright.
Updates
- Release schedule clarification after Ocata [5]
- Nova placement/resource providers [6][12]
- Stuart McLaren stepping down from glance core [8]
Allowing Teams Based on Vendor-specific Drivers (cont) [1]
- Narrowed down options at last TC meeting to following [2]:
- Soft black (option 2): default option, had no negative feedback, represents the current status quo
- Soft white (option 4): had some positive feedback, folks liked it’s simple solution
- Grey (option 5): had the most positive feedback, but also the least amount of detail
- Other options’ patches are being abandoned
- Leaning towards an amended version of the ‘Grey’ proposal [10]
Community Goals for Pike (cont.) [3]
- Need feedback [4]
- Keep using openstack/governance for documenting goals
- Make sure to include guides
- Consider prioritization as it may not be possible to complete all the goals in the release
- Think about splitting larger goals to things that can be accomplished in a single release
- Involving users/operators through the Product WG and start face to face discussions on the Forums
Python changes in OpenStack CI [7]
- Python3.4 on a Trusty VM for older branches: stable/liberty and stable/mitaka
- Python3.5 on a Xenial VM for newer branches: stable/newton and master
- Python3.4 testing is disabled for these
- ACTION:
- Projects should enable voting for Python3.5 jobs or add them if they don’t exist yet
- Projects should remove Python3.4 jobs if they run only on master
Golang Technical Requirements [15]
- Activities to adopt Go into OpenStack are ongoing
- Areas need more discussion
- Common Libraries
- Dependency Management
- Candidates are govendor, glide and godep
- Release Deliverables
- Tags and/or build artifacts?
- AUTHORS and ChangeLog files can be autogenerated
- Oaktree has golang bindings and contains generated files
Upgrade readiness check in Nova [11]
- New, separate service
- Checks the system state and indicates how much it is ready to start the Ocata upgrade (success, warning, error)
Self-service branch management [13]
- Through openstack/releases repo
- Specify your needs in a patch [14] and the rest is automated after it’s merged
- New stable branch creation is best to happen close to the end of the cycle, when the bug fixing and stabilization activities are slowing down
Architectural discussion about nova-compute interactions [16]
- How do Nova, Neutron and Cinder interact with nova-compute
- Should nova-compute become a standalone shared service? [9]