OpenStack Weekly Community Newsletter (Oct.,10-16)

Website Automation

9 years ago

The content below is taken from the original (OpenStack Weekly Community Newsletter (Oct.,10-16)), to continue reading please visit the site. Remember to respect the Author & Copyright.

Liberty, the 12th release of OpenStack, came out yesterday

With 1,933 individual contributors and 164 organizations contributing to the release, Liberty offers finer-grained management controls, performance enhancements for large deployments and more powerful tools for managing new technologies such as containers in production environments: Learn what’s new

Break down those silos, OpenStack

“The projects need to come together to develop consistent formats, approaches and messaging,” says Rochelle Grober, senior software architect at Huawei Technologies and active member of the OpenStack community.

The Road to Tokyo

The OpenStack Summit Tokyo will sell out! Register NOW!
The schedule and mobile app for the OpenStack Summit in Tokyo are now available
- If you have already downloaded an OpenStack Summit mobile app before, no need to do it again! Just refresh your existing app.
OpenStack training sessions available in Tokyo
- Several ecosystem companies are offering training in Tokyo during the week of the Summit. Check out the sessions available and plan your travel accordingly
The Summit maps are now available online
Speakers, sponsors, and ATC registration codes deactivate 10/19, so register now!

Community feedback

OpenStack is always interested in feedback and community contributions, if you would like to see a new section in the OpenStack Weekly Community Newsletter or have ideas on how to present content please get in touch: community@openstack.org.

Reports from Previous Events

None this week

Deadlines and Contributors Notifications

Outreachy Mentorship Application deadline: Nov., 02, 2015, 07:00 pm UTC
Call for papers:
- FOSDEM’16 deadline: October 30, 2015
- OSCON 2016 deadline: November 24, 2015
- Continuous Lifecycle London Deadline: December 1, 2015
- PyCon 2016 deadline: Jan 3, 2016
- USENIX Annual Technical Conference 2016 deadline: February 1, 2016

Security Advisories and Notices

None this week

Tips ‘n Tricks

By Nir Yechiel and Jiri Benc: Troubleshooting Networking with RHEL OpenStack Platform: meet ‘plotnetcfg’

Upcoming Events

What You Need to Know From the Developer’s List

Success Bot Says

ttx: Another OpenStack Release!
With help of jesusaurus, the infra team has deployed Kibana 3. First steps in upgrading elastic search cluster.
shamail: Product Working Group wiki fully updated [1]
tristanC: 6 new TC members have been elected[2]
AJaegar: OpenStack API Quick Start converted to RST [3], and translated to German [4] and Japanese [5].
reed: section 2 and 3 of the OpenStack Shade tutorial merged. Now work on section [6].
sirushti: Heat just announced support for Python 3.4 [7].
AJaegar: All Documentation manuals have been updated with content for Liberty [8].

Upgrade to Gerrit 2.11

The OpenStack Infra team would like to upgrade from Gerrit 2.8 to 2.11.
Proposing to do the upgrade shortly after the Mitaka summit.
Motivation: Take advantage of some of the new REST API, ssh commands, and stream events features.
There is a big UI change in 2.11, in which 2.8 includes both the old and new style.
Preview 2.11 [9].
If you don’t like Gerrit 2.11, give Gertty [10] a try.

Service Catalog: The Next Generation (Cont.)

Continuing from last week summary…
Sean Dague realizes that while people want to go in much more radical directions here, we should be careful. This is not a blank slate, as there are enough users using it that we must do careful shifts that enable a new thing similar to the old thing.
- Moving away from REST is too much, at least in the next 6 to 12 months.
- Getting a service catalog over REST without auth, or tenant IDs gets us somewhere to figure out a DNS representation.

Establishing Release Liaisons for Mitaka

Doug Hellmann writes that the release management team relies on liaisons from each project to be available for coordination for work across all teams.
- Responsibilities of release liaisons [11].
- Signup [12].

Release Communication During Mitaka

Doug Hellmann begins one of many emails describing difference in the way we handle release management for the Mitaka cycle.
In the past, we’ve had communication issues where project team leads didn’t see or pay attention to release related announcements.
This email was sent to the list and individual project team leads, to improve the odds that all will see it.
“[release]” topic tag on the openstack-dev mailing list will be used.
- All project team leads and release liaison should configuring their email client to ensure the messages are visible.

Requests + urllib3 + distro package (cont.)

Continuing discussions from last week…
Robert Collins comments a trivial workaround is to always use virtualenvs and not system-site-packages.
- Has OpenStack infra team considered using system-site-packages?
  - Yes, but we take advantage of the python ecosystem uploading new releases to PyPI. We can then pretty instantly test compatibility of our software with new releases of dependencies.
A way forward is:
- Get distros to fix their requests python dependencies
  - Ubuntu [13]
  - Fedora [14][15][16]
  - Fix existing known bugs in pip where such dependencies are violated by some operations.
- Stop using vendorized version of requests and fork the project to use dependencies it should from the start.
- Convince upstream to stop vendorizing urllib3.
- Always use distro packages of requests, never from virtual environments.

Scheduler Proposal (cont.)

Continuing from last week’s summary…
Ed notes that Josh Harlow’s solution isn’t too different than the current design of hosts sending their state to the scheduler.
The reason for Cassandra proposal was to eliminate the duplication and have resources being scheduler and the scheduler itself all working with the same data.
- This is the intent of the current design. The data can never be perfect, so work with what you have and hope the rest of the system deals with your mistakes and gracefully retry. (e.g. scheduled compute node no longer has resources to accommodate a request.)
- To make this solution possible for downstream distributions and/or OpenStack users) you have to solve:
  - Cassandra developers upstream should start caring about OpenJDK.
  - Or Oracle should make its JVM free software.
- Clint notes that Cassandra does not recommend OpenJDK [17].
  - Thomas adds:
    - Upstream does not test against OpenJDK.
    - They close bugs without fixing them when it only affects OpenJDK.
Thierry is generally negative about Java solutions as this being one of the reasons [18]. The free software JVM is not on par with the non-free JVM. We then indirectly force our users to use a non-free dependency. When the java solution is the only solution for a problem space, that might still be a good trade-off versus reinventing the wheel. However, for distributed locks and sharing state, there are some other good options out there.
- Clint mentions that Zookeeper is different from Cassandra. He has had success with OpenJDK. It’s also available on Debian/Ubuntu making access for developers much easier.