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

Kilowatts for Humanity harnesses the wind and sun to electrify rural communities

OpenStack-powered DreamCompute cloud computing helps keep rural microgrids up and running

OpenStack and Network Function Virtualization, the backstory

Jonathan Bryce, OpenStack executive director, gave a keynote at the OPNFV Summit where he talked about the two communities.

Fighting cloud vendor lock-in, manga style

To celebrate the OpenStack community and Liberty release, the Cloudbase Solutions team created a one-of-a-kind printed comic packed with OpenStack puns and references to manga and kaiju literature.

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: [email protected].

Reports from Previous Events 

• Local users steal the spotlight at OpenStack Day Benelux
• Sitting down with NTT Group, the Superuser Awards winner at the OpenStack Summit Tokyo

Deadlines and Contributors Notifications

• Call for papers:
  • 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 Adam Gandelman: Blog: Astara Liberty Release
• By Chris Price: OPNFV creates more features, documentation with second release, Brahmaputra

OpenStack Developer Mailing List Digest November 7-13

Upcoming Events 

• Nov 14, 2015 How to make multi-tenant service based on Keystone?
• Nov 15 – 20, 2015 Supercomputing 15 Austin, TX, US
• Nov 15, 2015 奔跑吧，OpenStack! ——UnitedStack与您⾯对⾯·北京站·东京峰会见闻专场 Beijing, CN
• Nov 16, 2015 November Meetup Manchester, GB
• Nov 17 – 18, 2015 Monitoring A Multi-Tenant Cloud by Datadog/ Neutron Networking by Midokura New York, NY, US
• Nov 18, 2015 Deploying OpenStack Using OSAD Houston, TX, US
• Nov 18, 2015 Meetup#18 – Bundles d’applications sur OpenStack @POSS La Plaine Saint-Denis, FR
• Nov 18, 2015 Tokyo Aftermath Meetup London, GB
• There are several events you won’t want to miss out on Nov 18-19, see the full list here

The content below is taken from the original (OpenStack Developer Mailing List Digest November 7-13), to continue reading please visit the site. Remember to respect the Author & Copyright.

New Management Tools and Processes for stable/liberty and Mitaka

• For release management, we used a combination of launchpad milestone pages and our wiki to track changes in releases.
• We used to pull releases notes for stable point releases at the time of releases.
• Release managers would work with PTLs and release liaisons at each milestone to update launchpad to reflect the work completed.
• All this requires a lot of work of the stable maintenance and release teams.
• To address this work with the ever-growing set of project, the release team is introducing Reno for continuously building release notes as files in-tree.
  • The idea is small YAML files, usually one per note or patch to avoid merge conflicts on back ports, which are then compiled to a readable document for readers.
  • ReStructuredText and Sphinx are supported for converting note files to HTML for publication.
  • Documentation for using Reno is available [1].
• Release liaisons should create and merge a few patches for each project between now and Mitaka-1 milestone:
  • To the master branch, instructions for publishing the notes. An example of Glance [2].
  • Instructions for publishing in stable/liberty of the project. An example with Glance [3].
  • Relevant jobs in project-config. An example with Glance [4].
  • Reno was not ready before the summit, so the wiki was used for release notes for the initial Liberty releases. Liaisons should covert those notes to Reno YAML files in stable/liberty branch.
• Use the topic ‘add-reno’ for all patches to track adoption.
• Once liaisons have done this work, launchpad can stop being used for tracking completed work.
• Launchpad will still be used for tracking bug reports, for now.

Keeping Juno “alive” For Longer

• Tony Breeds is seeking feedback on the idea of keeping Juno around a little longer.
• According to the current user survey [5], Icehouse still has the biggest install base in production clouds. Juno is second, which means if we end of life (EOL) Juno this month, ~75% of production clouds will be running a EOL’d release.
• The problems with doing this however:
  • CI capacity of running the necessary jobs of making sure stable branches still work.
  • Lack of resources of people who care to make sure the stable branch continues to work.
  • Juno is still tied with Python 2.6.
  • Security support is still needed.
  • Tempest is branchless, so it’s running stable compatible jobs.
• This is acknowledged as a common request. The common answer being “push more resources in fixing existing stable branches and we might consider it”.
• Matt Riedmann who works in the trenches of stable branches confirms stable/juno is already a goner due to requirements capping issues. You fix one issue to unwedge a project and with global-requirement syncs, we end breaking 2 other projects. The cycle never ends.
• This same problem does not exist in stable/kilo, because we’ve done a better job of isolating versions in global-requirements with upper-constants.
• Sean Dague wonders what are the reasons that keep people from doing upgrades to begin with. Tony is unable to give reasons since some are internal to his companies offering.

Oslo Libraries Dropping Python 2.6 compatibility

• Davanum notes a patch to drop py26 oslo jobs [6].
• Jeremy Stanley notes that the infrastructure team plans to remove CentOS 6.X job workers which includes all python 2.6 jobs when stable/juno reaches EOL.

Making Stable Maintenance its own OpenStack Project Team

• Thierry writes that when the Release Cycle Management team was created, it just happen to contain release management, stable branch management, and vulnerability management.
  • Security Team was created and spun out of the release team today.
• Proposal: spin out the stable branch maintenance as well.
  • Most of the stable team work used to be stable point release management, but as of stable/liberty this is now done by the release management team and triggered by the project-specific stable maintenance teams, so there is no more overlap in tooling used there.
  • Stable team is now focused on stable branch policies [7], not patches.
  • Doug Hellmann leads the release team and does not have the history Thierry had with stable branch policy.
  • Empowering the team to make its own decisions, visibility, recognition in hopes to encourage more resources being dedicated to it.
    • Defining and enforcing stable branch policy.
    • If team expands, it could own stable branch health/gate fixing. The team could then make decisions on support timeframes.
  • Matthew Treinis disagrees that the team separation solves the problem of getting more people to work on gate issues. Thierry has evidence though that making a its own project will result in additional resources. The other option is to kill stable branches, but as we’ve seen from the Keeping Juno Alive thread, there’s still interest in having them.

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

Superuser TV

Introduced at the Tokyo Summit, Superuser TV offers community and industry insights, plus educational topics to support the OpenStack community. With content ranging from deployments to diversity, from emerging technologies to cloud strategy, Superuser TV is aiming to provide the community with access to a variety of perspectives and knowledge

October 2015 user survey highlights increasing maturity of OpenStack deployments

60 percent of deployments in production and high rates of adoption of OpenStack’s core services are key findings from the report released by the User Committee. The full report can be downloaded here: http://bit.ly/1NUFU2w

Eliminating “Not-Invented-Here” Syndrome

Why embracing this notion is the key to unlock an open data center infrastructure, according to Boris Renski, the co-founder and CMO of Mirantis.

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: [email protected].

Reports from Previous Events 

• OpenStack Summit Tokyo – Final Summary

• Why OpenStack Neutron just grabbed center stage

• Finding your way around OpenStack: professional certification and the project navigator

• Your OpenStack questions answered, a block storage battle and mobile eats the world

• Domo arigato Japan!

Deadlines and Contributors Notifications

• Call for papers:
  • 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 Russell Bryant: Open Virtual Network tutorial
• By Gal Sagie: What you need to know about Dragonflow for the OpenStack Liberty release

Upcoming Events 

• Nov 07, 2015 OSATH – FOSSCOMM 2015 Aigaleo, GR
• Nov 11, 2015 whereis instance_ha + OpenStack Tokyo Summit Recap
• Nov 12, 2015 8. Meetup, Konu: OpenStack Plugin Development 101 Ankara, TR

What you need to know from the developer’s list

• Success Bot Says

  • calebb: Shade now supports volume snapshots
  • pleia2: Launched code search [1].
  • sdague: grenade-multinode live upgrade tests now running on nova non voting
  • AJaeger: Contributors guide is published [2].
  • Tell us yours via IRC with a message “#success [insert success]”

• Upgrading Elastic Search Cluster Monday

  • November 9th 1700UTC
  • Requires a cluster restart, in which people won’t be able to do searches during that time.
  • New features from upgrade:
    • Aggregations
    • Rolling upgrades within a major release
    • Should improve performance

• Release Team Communication Changes

  • IRC channel change from #openstack-relmgr-office to #openstack-release
  • “Office hours” are being dropped.
    • Just drop by the channel or on the dev list with subject containing “[release]” anytime you need something.

• Deprecation for Untagged Code

  • Ironic tries to keep master backwards compatible. There are deployers doing continuous deployments of Ironic off of master.
  • Based on the deprecation tag policy [3], it only covers released and tagged code, but not unreleased code or features introduced in an intermediate release.
  • A proposal [4] by Jim:
    • Three month deprecation period is needed for features that were never released.
    • A feature that was introduced in a intermediate release needs to be deprecated in the next intermediate release or coordinated release, and supported until the next release and 3 months.

• Outcome of Distributed Lock Manager Discussion @ the Summit

  • There was a two part session at the summit [5]
  • Previously, there was an unwritten policy that DLMs should be optional, which led to writing poor DLM-like things backed by databases.
  • Continuing our existing pattern of usage like databases and message-queues, we’ll use an oslo abstraction layer: tooz [6].
  • Current OpenStack project requirements that surfaced in discussion for DLMs, it’s likely that Consul, Etcd and Zoo Keeper will be fine to use via Tooz. No project required a fair locking implementation in the DLM.
  • We want to avoid the situation of unmaintained drivers. We adopted a similar requirement from oslo.messaging driver requirements [7]:
    • Two developers responsible for it
    • Gating functional tests that use dsvm
    • Test drivers in-tree need to be clearly referenced as a test driver in the module name.
  • Davanum brings in Devstack ZooKeeper support [8].
  • An etcd driver is in review for Tooz [9].
  • A Consul driver in Tooz is also planned [10].
  • Concerns raised about the default DLM driver being ZooKeeper:
    • It’s a new platform for operators to understand
    • We don’t know how well ZooKeeper will work with openjvm as oppose to Oracle’s JVM.

• Troubleshooting Cross-Project Communication

  • Evolve the current cross-project meeting to an “as needed” rotation, held at any time on Tuesdays or Wednesdays.
  • Based on feedback [11] it’s difficult to have meetings at different times on Tuesday and Wednesdays.
  • There was consensus that the meeting can be “as needed” on Tuesday, and that most announcements will happen in the mailing list, and sometimes show up in this weekly Dev List Summary.

• API For Getting Only Status of Resources

  • Projects like Heat,Tempest, Rally, and other projects that work with resources are polling for updates on asynchronous operations.
  • Boris proposes having API’s expose the ability to just get the status by UUID, instead of fetching all data on a resource.
  • Clint suggests instead of optimizing for polling, we should revisit the proposal for a pub/sub model, so users can subscribe to updates for resources.
  • Sean suggests near term work around is to actually use Searchlight, which today monitors the notification bus for Nova.
    • Searchlight is hitting the Nova API more than ideal, but at least it’s one service.
    • Longer term we need a dedicated event service in OpenStack. Everyone wants web sockets, but anticipating 10,000+ open web sockets, this isn’t just a bit of python code, but a highly optimized server underneath.