Announcing firehose.openstack.org
A MQTT based unified message bus for infra services.
This allows a single place to go for consuming messages of events from infra services.
Two interfaces for subscribing to topics:
MQTT protocol on the default port
Websockets over port 80
Launchpad and gerrit events are the only things currently sending message to firehose, but the plan is to expand this.
An example[1] of gerritbot on the consuming side, which has support for subscribing to gerrit event stream over MQTT.
A spec giving details on firehose[2].
Docs on firehose[3].
Full thread
Release countdown for week R-1, 26-30 Focus: All teams should be working on release-critical bugs befor ethe final release. General 29 th September is the deadline for the new release candidates or release from intermediary projects. Quiet period to follow before the last release candidates on 6 th October. Release actions: Projects not following the milestone-based release model who want a stable/newton branch created should talk to the release team. Watch for translation patches and merge them quickly to ensure we have as many user-facing strings translated as possible in the release candidates. If your project has already been branched, make sure those patches are applied to the stable branch. Liaisons for projects with independent deliverables should import the release history by preparing patches to openstack/release. Important Dates: Newton last RC, 29 September Newton final release, 6 October Newton release schedule[4] Full thread Removal of Security and OpenStackSalt Project Teams From the Big Tent The Security and OpenStackSalt projects are without PTLs. Projects leaderless default to the Technical Committee for decision of what to do with the project[5]. Majority of the Technical Committee has agreed to have these projects removed. OpenStackSalt is a relatively new addition to the Big Tent, so if they got their act together, they could be reproposed. We still need to care about security., and we still need a home for the vulnerability management team (VMT). The suggested way forward is to have the VMT apply to be its own official project team, and have security be a working group. The Mitaka PTL for the Security mentions missing the election date, but provides some things the team has been working on: Issuing Security Notes for Glance, Nova, Horizon, Bandit, Neutron and Barbican. Updating the security guide (the book we wrote on securing OpenStack) Hosting a midcycle and inducting new members Supporting the VMT with several embargoed and complex vulnerabilities Building up a security blog Making OpenStack the biggest open source project to ever receive the Core Infrastructure Initative Best Practices Badge Working on the OpenStack Security Whitepaper Developing CI security tooling such as Bandit One of the Technical Committee members privately received information that explains why the security PTL was not on top of things. With ~60 teams around there will always be one of two that miss, but here we’re not sure it passes the bar of “non-alignment with the community” that would make the security team unfit to be an official OpenStack Team. Full thread [1] http://git.openstack.org/cgit/openstack-infra/gerritbot/commit/?id=7c6e57983d499b16b3fabb864cf3b [2] http://specs.openstack.org/openstack-infra/infra-specs/specs/firehose.html [3] http://docs.openstack.org/infra/system-config/firehose.html [4] http://releases.openstack.org/newton/schedule.html [5] http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections